JP2016157358A

JP2016157358A - Ｄｒサイト切替先選定装置および方法

Info

Publication number: JP2016157358A
Application number: JP2015036032A
Authority: JP
Inventors: 玲町野; Rei Machino
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2015-02-26
Filing date: 2015-02-26
Publication date: 2016-09-01

Abstract

【課題】ＤＲサイトを選定する上で災害や障害時におけるＤＲシステムのサーバやストレージ、ネットワークのリソースの変化は激しく、特に災害や障害時には多くの企業が特定のＤＲサイトへ集中してアクセスすることが想定されるため、災害や障害時にリソース状況を見て切替先を選択しても、切替が同じタイミングに集中してしまうと、切り替えてすぐに、処理が重くなってしまうケースが考えられる。【解決手段】上記課題を解決する為に、災害や障害が発生した際に、システムを切り替えた場合に他のシステムの切替が集中しないＤＲサイトを、システムの切替先として特定する切替先選定処理部を有する。【選択図】図１

Description

本発明は、メインサイトを切り替えるＤＲサイトの選択技術に関する。

これまでのＤＲサイトは、本番稼働しているシステムの拠点であるメインサイトと同じ構成のシステムをＤＲシステムとして遠隔地に１拠点用意し、災害や障害時に準備していたＤＲサイトのＤＲシステムへ切替を行っていた。具体的には、東日本をメインサイトとしてシステムを設け、災害や障害が発生した場合はＤＲサイトとして準備していた西日本のＤＲシステムにメインサイトのシステムの切替を行うといったことが一般的である。

しかし、安価にサーバやストレージのサービスを提供する海外のクラウドベンダーの出現や、東日本大震災の影響により企業はＤＲサイトを国内だけでなく海外にも準備をするようになってきた。具体的には、従来のＤＲサイトに加え、基幹系システムや分析系システム等の切替対象となるシステム別に広範囲に複数のＤＲサイトを準備するといったことである。

複数のＤＲサイトから切替対象のＤＲサイトを選択する技術として、特許文献１のように、災害や障害が発生した際に事前に定義していた切替のためのシステム情報を元に各ＤＲサイトに用意しているＤＲシステムのサーバやストレージ、ネットワークのリソース状況を確認してから切替先を選択する旨開示されている。

特開２００９−１３４６８７号公報

ＤＲサイトを選定する上で災害や障害時におけるＤＲシステムのサーバやストレージ、ネットワークのリソースの変化は激しく、特に災害や障害時には多くの企業が特定のＤＲサイトへ集中してアクセスすることが想定されるため、災害や障害時にリソース状況を見て切替先を選択しても、切替が同じタイミングに集中してしまうと、切り替えてすぐに、処理が重くなってしまうケースが考えられる。特許文献１ではこのような状況が考慮されていない。

上記課題を解決するために、災害や障害が発生した際に、システムを切り替えた場合に他のシステムの切替が集中しないＤＲサイトを、システムの切替先として特定する切替先選定処理部を有することを特徴とする。

本発明によって、より効率的なＤＲサイトを選択することができる。

ＤＲシステムへの切替先を決定するシステム全体の構成図の例である。ＤＲシステムへ負荷を与える際のシナリオを管理するサーバの例である。ＤＲシステムへ負荷を与え、その時のＤＲシステムのリソース情報を管理するサーバの例である。平常稼働時と災害や障害時のリソース情報のマッチングによってシステムの切替先を選定するサーバの例である。平常時実行処理部および災害/障害時実行処理部によって出された負荷に応答し、その時のＤＲシステムのリソース情報を管理するサーバの例である。メインサイトで稼働しているシステムのログ情報のデータ例を示す図である。メインサイトで稼働しているシステムのログ情報から、稼働システムのＣＰＵ使用率が最高値であった時間帯のログを抽出したデータ例を示す図である。平常稼働時にＤＲシステムへ負荷を与えた際のリソース情報のデータ例を示す図である。災害や障害時にＤＲシステムへ負荷を与えた際のリソース情報のデータ例を示す図である。ＤＲシステムに負荷を与えた際の各ＤＲサイトにおけるＤＲシステムのリソース情報のデータ例を示す図である。平常稼働時および災害や障害時にＤＲシステムに負荷を与えた際に得られたリソース情報の変動の許容範囲を定義したデータ例を示す図である。平常稼働時および災害や障害時にＤＲシステムに負荷を与えた際に得られたリソース情報とリソースの変動の許容範囲を元にマッチングをしたデータ例を示す図である。マッチング処理部によって特定したリソースの許容範囲内の項目の総数から切替先となるＤＲサイトを選定するデータ例を示す図である。ＤＲシステムへの負荷を与える際のシナリオを作成するフローチャートの例である。平常稼働時にＤＲシステムのリソース情報を収集するフローチャートの例である。災害や障害時にＤＲシステムのリソース情報を収集し、平常稼働時と災害や障害時のリソース情報のマッチングによってシステムの切替先を選定するフローチャートの例である。

以下、実施例について図面を用いて説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１は、メインサイトで稼働しているシステムを複数のＤＲサイトの中から災害や障害時の切替先を決定するためのシステム全体の構成図の例である。図１の構成では、複数のＤＲサイトの中から災害や障害を想定した負荷を与えるシミュレーションを行った上でメインサイトのシステムの切替先となるＤＲシステムを選定するために、「シミュレーションのシナリオ作成」「平常稼働時のシミュレーション」「災害や障害時のシミュレーションおよびＤＲサイトの選定」を考慮した構成になっている。

複数のＤＲサイトの中から災害や障害を想定したシミュレーションを行った上でメインサイトのシステムの切替先となるＤＲシステムを選定する図１の構成について、各構成部分のサーバやデータベースを図２〜図５を用いて説明する。本実施例では、複数のサーバでの構成としたが、これに限定されるものではなく、各サーバの処理部やデータベースをひとつのサーバ内で持つこととしてもよい。各処理部やデータベースをひとつにまとめた場合、サーバがＤＲサイト切替先選定装置となる。

また、本発明に関する具体的なデータ項目について、図６〜図１３を用いて説明する。さらに、「シミュレーションのシナリオ作成」におけるフローを図１４で、「平常稼働時のシミュレーション」におけるフローを図１５で、「災害や障害時のシミュレーションおよびＤＲサイトの選定」におけるフローを図１６で説明する。

災害や障害時にはＤＲシステムのサーバやストレージ、ネットワークのリソースの空き状況を確認する必要があるが、災害や障害時だけの確認では、災害や障害によってＤＲシステムへのアクセスが集中しているのか判断することができないため、システムの切替後にサーバやストレージ、ネットワークのリソース不足に伴うシステムダウン等の障害が発生することが想定される。

そこで本発明は、災害や障害時のＤＲシステムのリソース状況を確認するだけでなく、平常稼働時においてもＤＲシステムのサーバやストレージ、ネットワークのリソース状況を確認することで災害や障害によってＤＲシステムへのアクセスが集中しているのか判断した上でＤＲサイトを選定し、システムの切替後も安定稼働を実現する。特に、メインサイトのシステムの稼働状況を元に複数のＤＲサイトへ負荷を与えるシナリオを作成し、作成したシナリオを平常稼働時と災害や障害時に実装することで、両者を実装した際のＤＲシステムのサーバやストレージ、ネットワークのリソース状況において、想定負荷の差の小さいＤＲサイトを選定し、切替先を決定する。

図１において、ユーザ端末１０１は本発明を利用するユーザが操作するシステムである。メインサイト１０２は本番稼働しているシステムの拠点である。基幹システム１０３および分析系システム１０４はメインサイト１０２で本番稼働しているシステムの例である。監視システム１０５はメインサイト１０２で稼働しているシステムのログ情報を元に複数のＤＲサイト１１５のＤＲシステム１１６へシミュレーションを行うシナリオの作成、およびシナリオの実装と、ＤＲシステム１１６のリソース情報の収集と、平常稼働時および災害や障害時におけるリソース情報のマッチングと、マッチング結果に基づくＤＲサイト１１５の選定を実施するシステムの例である。挙動定義サーバ１０６はメインサイト１０２で稼働しているシステムのログ情報を収集するログ収集処理部１０７と、ログ情報を元に複数のＤＲサイト１１５のＤＲシステム１１６へシミュレーションを行うシナリオの作成を行うログ分析処理部１０８を持つサーバの例である。挙動実行サーバ１０９はログ分析処理部１０８が作成したシナリオを元に、平常稼働時にＤＲサイト１１５のＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を収集する平常時実行処理部１１０と、ログ分析処理部１０８が作成したシナリオを元に、災害や障害時にＤＲサイト１１５のＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を収集する災害/障害時実行処理部１１１を持つサーバの例である。切替先選定サーバ１１２は平常時実行処理部１１０および災害/障害時実行処理部１１１が収集したＤＲシステム１１６のリソース情報を元にマッチングを行うマッチング処理部１１３と、マッチング処理部１１３の結果から切替先となるＤＲサイト１１５を選定する切替先選定処理部１１４を持つサーバの例である。ＤＲサイト１１５は切替対象となるＤＲシステム１１６の拠点である。監視システム１０５の挙動応答サーバ１１７は平常時実行処理部１１０および災害/障害時実行処理部１１１の負荷を受けてＤＲシステム１１６へ負荷を与えた際のリソース情報を収集する応答処理部１１８と、その時のリソース情報をメインサイト１０２へ送付する負荷情報処理部１１９を持つサーバの例である
図２は、ＤＲシステム１１６へ負荷を与える際のシナリオを管理するサーバの例である。ログ収集処理部１０７がメインサイト１０２で稼働しているシステム別にログ情報を収集しログ収集管理ＤＢ２０１へログ情報を格納する。その後、ログ分析処理部１０８がログ収集日においてメインサイト１０２で稼働しているシステム別にＣＰＵ使用率が最高値になる時間帯を特定し、その時間帯のログをログ収集管理ＤＢ２０１から抽出し、ログ分析管理ＤＢ２０２へ格納する。

図３は、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を管理するサーバの例である。平常稼働時に平常時実行処理部１１０がログ分析管理ＤＢ２０２に格納しているログ情報を元にその場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与える。さらに、メインサイト１０２へ送付されたリソース情報を平常時実行処理部１１０が受け取り、平常時情報管理ＤＢ３０１に格納する。ここで、ログ情報をもとに負荷を与えているが、これに限定されるものではなく、メインサイト１０２を各ＤＲサイト１１５へ移行した場合の負荷を再現できるものならばこれに限定されない。

また、災害や障害時に災害/障害時実行処理部１１１がログ分析管理ＤＢ２０２に格納しているログ情報を元にその場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与える。さらに、メインサイト１０２へ送付されたリソース情報を災害/障害時実行処理部１１１が受け取り、災害/障害時情報管理ＤＢ３０２に格納する。平常時実行処理部１１０とは、平常時にＤＲサイト１１５へ移行した場合の負荷を見るもので、災害／障害時実行処理部１１１は、災害や障害時にＤＲサイト１１５へ移行した場合の負荷を見るものである。

図４は、平常稼働時と災害や障害時のリソース情報のマッチングによってシステムの切替先を選定するサーバの例である。平常時実行処理部１１０および災害/障害時実行処理部１１１によって格納された各ＤＲサイト１１５のＤＲシステム１１６のリソース情報を用いて、マッチング処理部１１３がリソースの変動の許容範囲が定義されているポリシー管理ＤＢ４０２を元にマッチングを行い、マッチング結果をマッチング結果管理ＤＢ４０１へ格納する。切替先選定処理部１１４がマッチング結果管理ＤＢ４０１に格納している内容において、各データ項目のマッチング数が多いＤＲサイト１１５を選定し、切替先となるＤＲサイト１１５として決定する。

図５は、平常時実行処理部１１０および災害/障害時実行処理部１１１によって出された負荷に応答し、その時のＤＲシステム１１６のリソース情報を管理するサーバの例である。各ＤＲサイト１１５の応答処理部１１８が平常時実行処理部１１０および災害/障害時実行処理部１１１によって出された負荷に応答し、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を応答情報管理ＤＢ５０１へ格納する。負荷情報処理部１１９が応答情報管理ＤＢ５０１に格納しているリソース情報をメインサイト１０２へ送付する。

図６〜図１３では本発明に関する具体的なデータ項目について説明する。図６〜図７ではＤＲサイト１１５のＤＲシステム１１６へ負荷を与える際のシナリオ作成の流れについて説明する。図８〜図１０では作成したシナリオに沿って平常稼働時および災害や障害時にＤＲシステム１１６へ負荷を与えた際に得るリソース情報取得の流れについて説明する。図１１〜図１３では平常稼働時および災害や障害時に取得したＤＲシステム１１６のリソース情報を元にＤＲシステム１１６への切替が集中していないＤＲサイト１１５の選定の流れについて説明する。

図６は、メインサイト１０２で稼働しているシステムのログ情報のログ収集管理ＤＢ２０１のデータ例を示す図である。対象システム６０１はメインサイト１０２で稼働しているシステムを表す。日時６０２は対象システム６０１でのログの日時、ユーザＩＤ６０３は管理しているユーザのＩＤ、イベント内容６０４はユーザＩＤ６０３が実行しているイベントの内容を表している。

本実施例ではログ収集の対象システムとして分析系システム１０４を考える。そのため、ログ収集処理部１０７は分析系システム１０４のログを毎日０：００に収集し、ログ収集管理ＤＢ２０１へ格納する。格納されたログ内容については、対象システム６０１は分析系システム１０４、日時６０２は分析系システム１０４のログ日時、ユーザＩＤ６０３は分析系システム１０４において管理しているユーザのＩＤ、イベント内容６０４は分析系システム１０４において管理しているユーザＩＤ６０３が実行しているイベントになる。

なお、図６のデータ項目およびログを収集する時間帯については一例であり、本発明の条件をすべて満たすとは限らない。

図７は、メインサイト１０２で稼働しているシステムのログ情報から、稼働システムのＣＰＵ使用率が高い時間帯のログを抽出したログ分析管理ＤＢ２０２のデータ例を示す図である。対象システム７０１はメインサイト１０２で稼働しているシステムを表す。日時７０２は対象システム７０１でのログの日時、ユーザＩＤ７０３は管理しているユーザのＩＤ、イベント内容７０４はユーザＩＤ７０３が実行しているイベントの内容を表している。

本実施例ではログ収集の対象システムとして分析系システム１０４を考えている。ログ分析処理部１０８は３０分間隔におけるＣＰＵ使用率が高い時間帯のログをログ収集管理ＤＢ２０１から抽出し、ログ分析管理ＤＢ２０２へ格納する。格納されたログ内容については、対象システム７０１は分析系システム１０４、日時７０２は分析系システム１０４のログ日時、ユーザＩＤ７０３は分析系システム１０４において管理しているユーザのＩＤ、イベント内容７０４は分析系システム１０４において管理しているユーザＩＤ６０３が実行しているイベントになる。ＣＰＵ使用率が高いとは一定の閾値以上になるかどうかで判定するように制御してもよい。また、ここではＣＰＵ使用率としているがこれに限定されるものではなく、リソースの値であればメモリやディスク容量であってもよいし、その複合でもよい。なお、図７のデータ項目およびＣＰＵ使用率を確認する時間の間隔については一例であり、本発明の条件をすべて満たすとは限らない。

図８は、平常稼働時にＤＲシステム１１６へ負荷を与えた際のリソース情報の平常時情報管理ＤＢ３０１のデータ例を示す図である。ＤＲサイト８０１は負荷を与える複数のＤＲサイト１１５、チェック日時８０２はＤＲサイト１１５のＤＲシステム１１６へ負荷を与えた際の日時、レスポンスタイム８０３はメインサイト１０２からＤＲサイト１１５を経由してメインサイト１０２へリクエストが返ってくる時間を表す。またＤＲシステム１１６のリソース情報として帯域幅８０４、ＣＰＵ使用率８０５、メモリ使用可能８０６、ディスク使用率８０７を想定する。

本実施例では、ＤＲサイト１１５のＤＲシステム１１６へ負荷を与えるシステムの対象として分析系システム１０４を考えている。平常時実行処理部１１０は平常稼働時にログ分析管理ＤＢ２０２に格納されている分析系システム１０４におけるログ情報を元に、その場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与え、各ＤＲサイト１１５別にリソース情報を平常時情報管理ＤＢ３０１に格納する。なお、図８のデータ項目は一例であり、本発明の条件をすべて満たすとは限らない。

図９は、災害や障害時にＤＲシステム１１６へ負荷を与えた際のリソース情報の災害／障害時情報管理ＤＢ３０２のデータ例を示す図である。ＤＲサイト９０１は負荷を与える複数のＤＲサイト１１５、チェック日時９０２はＤＲサイト１１５のＤＲシステム１１６へ負荷を与えた際の日時、レスポンスタイム９０３はメインサイト１０２からＤＲサイト１１５を経由してメインサイト１０２へリクエストが返ってくる時間を表す。またＤＲシステム１１６のリソース情報として帯域幅９０４、ＣＰＵ使用率９０５、メモリ使用可能９０６、ディスク使用率９０７を想定する。

本実施例では、ＤＲサイト１１５のＤＲシステム１１６へ負荷を与えるシステムの対象として分析系システム１０４を考えている。災害/障害時実行処理部１１１は災害や障害時にログ分析管理ＤＢ２０２に格納されている分析系システム１０４におけるログ情報を元に、その場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与え、各ＤＲサイト１１５別にリソース情報を災害/障害時情報管理ＤＢ３０２に格納する。なお、図９のデータ項目は一例であり、本発明の条件をすべて満たすとは限らない。

図１０は、ＤＲシステム１１６に負荷を与えた際の各ＤＲサイト１１５におけるＤＲシステム１１６のリソース情報の応答情報管理ＤＢ５０１のデータ例を示す図である。チェック日時１００１はＤＲサイト１１５のＤＲシステム１１６へ負荷を与えた際の日時、レスポンスタイム１００２はメインサイト１０２からＤＲサイト１１５を経由してメインサイト１０２へリクエストが返ってくる時間を表す。またＤＲシステム１１６のリソース情報として帯域幅１００３、ＣＰＵ使用率１００４、メモリ使用可能１００５、ディスク使用率１００６を想定する。

本実施例では、ＤＲサイト１１５のＤＲシステム１１６へ負荷を与えるシステムの対象として分析系システム１０４を考えている。各ＤＲサイト１１５の応答処理部１１８が平常時実行処理部１１０および災害/障害時実行処理部１１１によって出された負荷に応答し、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を応答情報管理ＤＢ５０１へ格納する。なお、図１０のデータ項目は一例であり、本発明の条件をすべて満たすとは限らない。

図１１は、平常稼働時および災害や障害時にＤＲシステム１１６に負荷を与えた際に得られたリソース情報の変動の許容範囲を定義したポリシー管理ＤＢ４０２のデータ例を示す図である。対象システム１１０１はメインサイト１０２で稼働するシステム、レスポンスタイム１１０２はメインサイト１０２からＤＲサイト１１５を経由してメインサイト１０２へリクエストが返ってくる時間を表す。またＤＲシステム１１６のリソース情報として帯域幅１１０３、ＣＰＵ使用率１１０４、メモリ使用可能１１０５、ディスク使用率１１０６を想定する。

本実施例では、システム切替の対象となるシステムとして分析系システム１０４を考えている。よって、リソース情報の変動の許容範囲は対象システム１１０１の分析系システム１０４を参照することになる。なお、図１１のデータ項目は一例であり、本発明の条件をすべて満たすとは限らない。

図１２は、平常稼働時および災害や障害時にＤＲシステム１１６に負荷を与えた際に得られたリソース情報とリソースの変動の許容範囲を元にマッチングをしたマッチング結果管理ＤＢ４０１のデータ例を示す図である。ＤＲサイト１２０１は負荷を与える複数のＤＲサイト１１５、チェック日時１２０２はマッチングを行った際の日時、レスポンスタイム１２０３はメインサイト１０２からＤＲサイト１１５を経由してメインサイト１０２へリクエストが返ってくる時間を表す。またＤＲシステム１１６のリソース情報として帯域幅１２０４、ＣＰＵ使用率１２０５、メモリ使用可能１２０６、ディスク使用率１２０７を想定する。

本実施例では、システム切替の対象となるシステムとして分析系システム１０４を考えている。マッチング処理部１１３は平常時情報管理ＤＢ３０１および災害/障害時情報管理ＤＢ３０２を元に各データ項目の差がポリシー管理ＤＢ４０２に定義された値を満たす場合のマッチング結果を「はい」、満たさない場合のマッチング結果を「いいえ」として検査を行い、そのマッチング結果をマッチング結果管理ＤＢ４０１へ格納する。

本検査方法を用いることで、災害や障害時のリソース情報を確認しただけでは予測できなかったリソースの変動を確認できるようになるため、システムの切替後も安定稼働が実現できると考える。

具体的には災害や障害時に取得したリソース情報である図９を確認すると、ＤＲサイトＡにおけるＣＰＵ使用率９０５は５０％、ＤＲサイトＣにおけるＣＰＵ使用率９０５は６０％であるため、システムの切替先としてＤＲサイトＡが適切だと考えることができる。しかし、平常稼働時のリソース情報である図８も同時に確認すると、ＤＲサイトＡにおけるＣＰＵ使用率８０５は２０％、ＤＲサイトＣにおけるＣＰＵ使用率８０５は５０％であり、その差分はＤＲサイトＡでは３０％、ＤＲサイトＣでは１０％であることから、ＤＲサイトＡへアクセスが集中していることが分かる。よって、リソースの変動が小さいＤＲサイトＣへシステムの切替を行う方が、システム切替後も安定稼働が可能だと判断する。

本実施例では更にポリシー管理ＤＢ４０２とマッチングして、その差が条件を満たしているかどうかを判定して、ＤＲサイト１１５へ切替可能かどうかを判定しているが、これに限定されるものでなく、マッチング処理をすることなしに平常時と災害や障害時の負荷の差が小さいところへ切替するよう制御してもよい。また、ここではＣＰＵリソースに注目して制御しているがこれに限定されるものではなく、メモリ使用やディスク使用率等、リソースを表すものならばよい。

マッチングする際に平常時情報管理ＤＢ３０１および災害/障害時情報管理ＤＢ３０２に格納されている各データ項目の値がある一定値を超えていた場合は、システムの切替後も安定稼働ができないと判断し、システムの切替先の対象外としてマッチング結果に「ＮＧ」を入力し、そのマッチング結果をマッチング結果管理ＤＢ４０１へ格納する。

本実施例では、災害や障害時に取得したリソース情報である図９を確認すると、ＤＲサイトＢにおけるＣＰＵ使用率９０５が８０％であることから、システムの切替え後も安定稼働ができないと判断し、システムの切替え先の対象外としてマッチング結果に「ＮＧ」と入力する。なお、図１２のデータ項目およびマッチング結果の表示形式は一例であり、本発明の条件をすべて満たすとは限らない。

図１３は、マッチング処理部によって特定したリソースの許容範囲内の項目の総数から切替先となるＤＲサイト１１５を選定する切替先選定ＤＢ４０３のデータ例を示す図である。対象システム１３０１はメインサイト１０２で稼働するシステム、ＤＲサイト１３０２は負荷を与える複数のＤＲサイト１１５、チェック日時１３０３はマッチングを行った際の日時を表す。

本実施例では、システム切替の対象となるシステムとして分析系システム１０４を考えている。切替先選定処理部１１４はマッチング結果管理ＤＢ４０１に格納されているマッチング結果を元に、各ＤＲサイト１１５の各データ項目においてマッチング結果が「はい」である数を集計し、その数が多いＤＲサイト１１５を切替先のＤＲサイト１１５として選定し、選定結果を切替先選定ＤＢ４０３に格納する。

具体的には、マッチング結果である図１２を確認すると、ＤＲサイトＡの「はい」の数は２つ、ＤＲサイトＢの「はい」の数は１つ、ＤＲサイトＣの「はい」の数は５つである。ＤＲサイトＢにおいては「ＮＧ」のデータ項目が存在するため、切替先として除外する。以上の結果から、分析系システム１０４におけるシステム切替先としてＤＲサイトＣが適切であると判断し、切替先をＤＲサイトＣとして切替先選定ＤＢ４０３に格納する。なお、図１３のデータ項目およびマッチング結果の表示形式は一例であり、本発明の条件をすべて満たすとは限らない。

図１４〜図１６では本発明に関する具体的なフローについて説明する。「シミュレーションのシナリオ作成」におけるフローを図１４で、「平常稼働時のシミュレーション」におけるフローを図１５で、「災害や障害時のシミュレーションおよびＤＲサイト１１５の選定」におけるフローを図１６で説明する。

図１４は、ＤＲシステム１１６への負荷を与える際のシナリオを作成するフローチャートの例である。ログ収集処理部１０７がメインサイト１０２で稼働しているシステム別にログ情報を収集しログ収集管理ＤＢ２０１へログ情報を格納する。その後、ログ分析処理部１０８がログ収集日においてメインサイト１０２で稼働しているシステム別にＣＰＵ使用率が最高値になる時間帯を特定し、その時間帯のログをログ収集管理ＤＢ２０１から抽出し、ログ分析管理ＤＢ２０２へ格納する。本実施例ではＣＰＵ使用率としているがこれに限定されるものではなく、リソースの使用率を表す情報ならばなんでもよい。

具体的には、ログ収集処理部１０７が毎日０：００に基幹システム１０３および分析系システム１０４のログ情報を収集し、ログ収集管理ＤＢ２０１に格納する。その後、ログ分析処理部１０８がログ収集日の基幹システム１０３および分析系システム１０４におけるＣＰＵ使用率が最高値になる時間帯を３０分間隔で分析し、その時間帯のログをログ収集管理ＤＢ２０１から抽出し、ログ分析管理ＤＢ２０２へ格納する。

本実施例ではログ収集の対象システムとして分析系システム１０４を考え、ログ収集処理部１０７は分析系システム１０４のログを毎日０：００に収集し、ログ収集管理ＤＢ２０１へ格納する。格納されたログ内容については、対象システム６０１は分析系システム１０４、日時６０２は分析系システム１０４のログ日時、ユーザＩＤ６０３は分析系システム１０４において管理しているユーザのＩＤ、イベント内容６０４は分析系システム１０４において管理しているユーザＩＤ６０３が実行しているイベントになる。

ログ分析処理部１０８は３０分間隔におけるＣＰＵ使用率が最高値であった時間帯のログをログ収集管理ＤＢ２０１から抽出し、ログ分析管理ＤＢ２０２へ格納する。格納されたログ内容については、対象システム７０１は分析系システム１０４、日時７０２は分析系システム１０４のログ日時、ユーザＩＤ７０３は分析系システム１０４において管理しているユーザのＩＤ、イベント内容７０４は分析系システム１０４において管理しているユーザＩＤ６０３が実行しているイベントになる。

図１５は、平常稼働時にＤＲシステム１１６のリソース情報を収集するフローチャートの例である。平常稼働時に平常時実行処理部１１０がログ分析管理ＤＢ２０２に格納しているログ情報を元にその場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与える。各ＤＲサイト１１５の応答処理部１１８が平常時実行処理部１１０によって出された負荷に応答し、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を応答情報管理ＤＢ５０１へ格納する。負荷情報処理部１１９が応答情報管理ＤＢ５０１に格納しているリソース情報をメインサイト１０２へ送付する。メインサイト１０２へ送付されたリソース情報を平常時実行処理部１１０が受け取り、平常時情報管理ＤＢ３０１に格納する。

本実施例では、ＤＲサイト１１５のＤＲシステム１１６へ負荷を与えるシステムの対象として分析系システム１０４を考え、平常時実行処理部１１０は平常稼働時にログ分析管理ＤＢ２０２に格納されている分析系システム１０４におけるログ情報を元に、その場合メインサイト１０２の分析系システム１０４に実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与え、各ＤＲサイト１１５別にリソース情報を平常時情報管理ＤＢ３０１に格納する。

各ＤＲサイト１１５の応答処理部１１８が平常時実行処理部１１０および災害/障害時実行処理部１１１によって出された負荷に応答し、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を応答情報管理ＤＢ５０１へ格納する。

図１６は、災害や障害時にＤＲシステム１１６のリソース情報を収集し、平常稼働時と災害や障害時のリソース情報のマッチングによってシステムの切替先を選定するフローチャートの例である。災害や障害時に災害/障害時実行処理部１１１がログ分析管理ＤＢ５０２に格納しているログ情報を元にその場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与える。各ＤＲサイト１１５の応答処理部１１８が災害/障害時実行処理部１１１によって出された負荷に応答し、ＤＲシステム１１６へ負荷を与え、その時のＤＲシステム１１６のリソース情報を応答情報管理ＤＢ８０１へ格納する。負荷情報処理部１１９が応答情報管理ＤＢ８０１に格納しているリソース情報をメインサイト１０２へ送付する。メインサイト１０２へ送付されたリソース情報を災害/障害時実行処理部１１１が受け取り、災害/障害時情報管理ＤＢ６０２に格納する。平常時実行処理部１１０および災害/障害時実行処理部１１１によって格納された各ＤＲサイト１１５のＤＲシステム１１６のリソース情報を用いて、マッチング処理部１１３がリソースの変動の許容範囲が定義されているポリシー管理ＤＢ７０２を元にマッチングを行い、マッチング結果を、マッチング結果管理ＤＢ７０１へ格納する。切替先選定処理部１１４がマッチング結果管理ＤＢ７０１に格納している内容において、各データ項目のマッチング数が多いＤＲサイト１１５を選定し、切替先となるＤＲサイトとして決定する。

本実施例では、システム切替の対象となるシステムとして分析系システム１０４を考えており、災害/障害時実行処理部１１１は災害や障害時にログ分析管理ＤＢ２０２に格納されている分析系システム１０４におけるログ情報を元に、その場合実行されていたジョブを各ＤＲサイト１１５へ再現し、ＤＲシステム１１６へ負荷を与え、各ＤＲサイト１１５別にリソース情報を災害/障害時情報管理ＤＢ３０２に格納する。

マッチング処理部１１３は平常時情報管理ＤＢ３０１および災害/障害時情報管理ＤＢ３０２を元に各データ項目の差がポリシー管理ＤＢ４０２に定義された値を満たす場合のマッチング結果を「はい」、満たさない場合のマッチング結果を「いいえ」として検査を行い、そのマッチング結果をマッチング結果管理ＤＢ４０１へ格納する。

また、マッチングする際に平常時情報管理ＤＢ３０１および災害/障害時情報管理ＤＢ３０２に格納されている各データ項目の値がある一定値を超えていた場合は、システムの切替後も安定稼働ができないと判断し、システムの切替先の対象外としてマッチング結果に「ＮＧ」を入力し、そのマッチング結果をマッチング結果管理ＤＢ４０１へ格納する。

本実施例では、災害や障害時に取得したリソース情報である図９を確認すると、ＤＲサイトＢにおけるＣＰＵ使用率９０５が８０％であることから、システムの切替後も安定稼働ができないと判断し、システムの切替先の対象外としてマッチング結果に「ＮＧ」と入力する。

切替先選定処理部１１４はマッチング結果管理ＤＢ４０１に格納されているマッチング結果を元に、各ＤＲサイト１１５の各データ項目においてマッチング結果が「はい」である数を集計し、その数が多いＤＲサイト１１５を切替え先のＤＲサイト１１５として選定し、選定結果を切替先選定ＤＢ４０３に格納する。

具体的には、マッチング結果である図１２を確認すると、ＤＲサイトＡの「はい」の数は２つ、ＤＲサイトＢの「はい」の数は１つ、ＤＲサイトＣの「はい」の数は５つである。ＤＲサイトＢにおいては「ＮＧ」のデータ項目が存在するため、切替先として除外する。以上の結果から、分析系システム１０４におけるシステム切替先としてＤＲサイトＣが適切であると判断し、切替先をＤＲサイトＣとして切替先選定ＤＢ４０３に格納する。

１０１：ユーザ端末、１０２：メインサイト、１０３：基幹システム、１０４：分析系システム、１０５：監視システム、１０６：挙動定義サーバ、１０７：ログ収集処理部、１０８：ログ分析処理部、１０９：挙動実行サーバ、１１０：平常時実行処理部、１１１：災害/障害時実行処理部、１１２：切替先選定処理部、１１３：マッチング処理部、１１４：切替先選定処理部、１１５：ＤＲサイト、１１６：ＤＲシステム、１１７：挙動応答サーバ、１１８：応答処理部、１１９：負荷情報処理部

Claims

災害や障害が発生した際に、システムを切り替えた場合に他のシステムの切替が集中しないＤＲサイトを、システムの切替先として特定する切替先選定処理部
を有する
ことを特徴とするＤＲサイト切替先選定装置。
請求項１に記載のＤＲサイト切替先選定装置であって、
前記切替先選定処理部が、
平常時にＤＲサイトにシステムを切り替えた場合の第一の負荷を特定し、災害や障害時のＤＲサイトにシステムを切り替えた場合の第二の負荷を特定し、前記第一の負荷と前記第二の負荷の差がより小さいＤＲサイトを負荷の大きくないＤＲサイトとして特定する
ことを特徴とするＤＲサイト切替先選定装置。
請求項１乃至請求項２のいずれか一項に記載のＤＲサイト切替先選定装置であって、
前記切替先選定処理部が
前記負荷の差をあらかじめ決められた閾値とマッチングさせ、条件を満たす場合にＤＲサイトを切替先として特定する
ことを特徴とするＤＲサイト切替先選定装置。
請求項１乃至請求項３のいずれか一項に記載のＤＲサイト切替先選定装置であって、
前記負荷を、当該メインサイトのリソースのログ情報を元に特定すること
を特徴とするＤＲサイト切替先選定装置。
災害や障害が発生した際に、システムを切り替えた場合に負荷の大きくないＤＲサイトを、システムの切替先として特定するステップ
を有する
ことを特徴とするＤＲサイト切替先選定方法。