JP6482984B2

JP6482984B2 - クラウド管理方法及びクラウド管理システム

Info

Publication number: JP6482984B2
Application number: JP2015164372A
Authority: JP
Inventors: 太郎北村; 真法堂宮; 卓也島川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2015-08-24
Filing date: 2015-08-24
Publication date: 2019-03-13
Anticipated expiration: 2035-08-24
Also published as: JP2017045079A

Description

本発明は、クラウドの管理システムに関する。

下記特許文献１では対象システムの障害を含むインシデントをインシデント情報として第１のデータベースに管理し、前記対象システムの構成を構成情報として第２のデータベースに管理する構成管理システムと連携し、担当者の端末に対して情報の画面を提供するサービスポータルシステムと連携し、前記対象システムの障害を含むインシデントを監視する障害監視システムと連携することが開示されている。

クラウド管理システムは、対象システムの構成、障害影響範囲及び障害影響先サービスを含むインシデント状況を可視化する画面を、前記構成情報及び前記インシデント情報を用いて作成し、担当者の端末に提供する第１の機能と、前記対象システムにおける障害許容性を考慮して設計される構成部位を含む構成を、構成管理モデルとして前記構成情報に設定する第２の機能を有する。

そして、構成管理モデルでは、障害許容性を考慮して設計される構成部位を含む各構成部位を第１の構成アイテムとして設定し、前記第１の構成アイテムについての障害許容性を第２の構成アイテムとして設定し、第１、第２の構成アイテムを含む構成アイテム間の依存関係性をリンクとして設定する。第１の機能による画面では、構成アイテムをリンクで接続した構造で、対象システムの構成管理モデル、障害影響範囲及び障害影響先サービスを含むインシデント発生状況を表示することが開示されている。

特開2012-38028

特許文献1では、クラウド環境や障害許容性などを考慮した構成の対象システムにおける障害影響範囲などの状況を可視化する技術が開示されているが、複数のクラウドシステムで構成されるハイブリッドクラウド環境で業務システムを構成したときに、どのクラウドシステムでインシデントが発生したのかをシステムの管理者に知らせることについては考慮されていない。
また、時間とともに変化するインシデントの重要性に基づいて、管理者が優先的に対応しなければならないインシデントを知らせることについても考慮されておらず、業務システムを構成する仮想計算機上で稼働する業務サーバが他のクラウドシステムへ移動したときに、どのクラウドシステムからのインシデント報告なのか、どの程度の影響があるのかとういうことを移動した先のクラウドシステムが提供するインシデント報告の仕組みを用いて管理者へ報告することについても考慮されていない。

上記課題は複数のクラウドシステムで稼働する仮想計算機上で動作する複数テナントの業務サーバのインシデントを管理するクラウド管理システムで、業務サーバからのインシデント情報を受信しマージするインシデント受信部と、マージされたインシデント情報の種別と発生時刻に基づいてインシデントの前記複数のクラウドシステム内での優先度を求める優先度判定部と、求められた優先度に従ってインシデント情報を出力する出力部を備えるシステムによって解決される。

上記システムで解決されない個々の課題については実施例に記載された構成要素を追加することにより解決されるであろう。

本発明によれば、クラウドを用いて実現される業務システムのインシデントに対処する管理者の負荷を軽減できる。

本実施例におけるクラウドシステムの構成を示すブロック図の例である。本実施例におけるクラウド管理システムの情報集約サーバのブロック図の例である。本実施例におけるクラウド管理システムのナビゲーションサーバのブロック図の例である。本実施例におけるテナントのブロック図の例である。本実施例におけるデータセンタのブロック図の例である。本実施例における物理計算機で稼働する監視サーバのブロック図の例である。本実施例におけるインシデント情報テーブルの例である。本実施例における稼働データ情報テーブルの例である。本実施例におけるシステム情報テーブルの例である。本実施例におけるインシデント対応テーブルの例である。本実施例における優先度付きインシデント情報のテーブルの例である。本実施例における稼働データ情報テーブルの例である。本実施例における重要稼働データテーブルの例である。本実施例におけるインシデント情報表示テーブルの例である。本実施例におけるシステム基盤情報テーブルの例である。本実施例におけるインシデント対応履歴テーブルの例である。本実施例におけるエスカレーション情報のテーブルの例である。本実施例におけるインシデント一覧画面の例である。本実施例におけるインシデント詳細表示画面の例である。本実施例における監視サーバの稼働データ監視フローチャートの例である。本実施例における監視サーバの業務ログ監視フローチャートの例である。本実施例における情報集約サーバの優先度定義フローチャート１の例である。本実施例における情報集約サーバの優先度定義フローチャート２の例である。本実施例におけるナビゲーションサーバのインシデント取得・登録フローチャートの例である。本実施例におけるナビゲーションサーバのインシデント一覧表示フローチャートの例である。本実施例における他クラウドシステムへの業務サーバ移行時のフローチャートの例である。

図１は、本実施例クラウド管理システム１０と管理対象のテナントのシステムの全体構成図である。本実施例ではクラウド管理システム１０がネットワーク機器を介してインターネット経由でデータセンタ1からデータセンタNへ接続されている。顧客のテナント１３である業務システムは複数のデータセンタを用いて実現されたものもあり、各々のデータセンタは異なる事業者が提供するデータセンタである場合も考えられる。

図２は、情報集約サーバ１１のブロック図である。情報集約サーバ１１は、受信部１０１とネットワークインタフェース部１０２を有し、テナントの業務サーバから送信されてくるインシデントや稼働データをネットワークインタフェース部１０２を介して、受信部１０１で受信する。主記憶領域１８に格納されCPU１５で実行される優先度判定部１１１は、受信したインシデントをシステム情報テーブル１２１、インシデント対応テーブル１２２、稼働データ情報テーブル１２３、重要稼働データテーブル１２４の情報に基づいて優先度を判定し、確定した優先度情報をインシデントに付加する。インシデント登録部１１２は、優先度を付加されたインシデントを優先度付きインシデント情報テーブル１２５に登録する。

図３は、ナビゲーションサーバ１２のブロック図である。ナビゲーションサーバ１２は、表示部２０１とネットワークインタフェース部２０２を有する。この例では表示部２０１がナビゲーションサーバ１２に含まれているが、インターネットに接続されたブラウザ経由で表示するようにしても良い。ナビゲーションサーバは、情報集約サーバ１１が保持する優先度付きインシデント情報テーブル１２５の情報をネットワークインタフェース部２０２を介して取得するためのインシデント取得部２１１を有している。優先度付きインシデント登録部２１２は、システム基盤情報テーブル２２１から、取得したインシデントに関連するシステム基盤情報を抽出し、インシデントにシステム基盤情報、インシデントIDを付加して、インシデント情報表示テーブル２２２に登録する。インシデント対応履歴登録部２１３は、新規インシデントが発生し、インシデント情報表示テーブル２２２へ登録する際や、運用者がインシデントの対応情報を入力した際にインシデント対応履歴テーブル２２３に入力された対応情報を登録する。インシデント一覧表示部２１４は、インシデント情報表示テーブル２２２からインシデント情報を読み出し、インシデント対応履歴テーブル２２３からインシデントに関連する対応情報を抽出し、インシデントに情報を付加する。インシデント一覧表示部２１４は、インシデント情報を優先度順に表示部２０１を介して画面に表示する。システム基盤情報登録部２１５は、業務サーバが他のクラウドシステムに移動した際に、業務サーバから送られてきた移動先のシステム基盤情報を受け取り、システム基盤情報テーブル２２１の該当するレコードの情報を書き換える。メール送信部２１６は、インシデント発生時や、業務サーバが他のクラウドシステムに移動した際に、エスカレーション情報テーブル２２４から通知先を読み出し、ネットワークインタフェース部２０２を介してメールを送信する。インシデント取得部２１１、優先度付きインシデント登録部２１２、インシデント対応履歴登録部２１３等の各処理部は主記憶領域１９に格納され、CPU１６で実行される。
図４は、テナント１３のブロック図である。テナント１３は、データセンタ２１を複数有し、データセンタ内には業務システム２２が複数存在する。データセンタ２１は、インターネット網と接続する回線を有し、業務システム２２はその回線を介してインターネットに接続する。

図５は、データセンタ２１のブロック図である。業務システム２２の物理計算機３２上には仮想化ソフト３３が搭載されており、仮想化ソフト３３上ではVM（Virtual Machine）３１が複数稼働する。仮想化されていない物理計算機３２はOS３４が動作しているものもある。

図６は、物理計算機上で稼働する監視サーバ３５０のブロック図である。監視サーバ３５０は業務サーバを実行するVMと同じVMで実行されても良いし、業務サーバを実行するVMと独立したVMで実行されても良い。VM３１には監視サーバ３５０がインストールされており、OSイベントログ３２１や業務ログ３２２を監視するログ監視部３０１、業務サーバの稼働データ３２３を監視する稼働データ監視部を有している。

監視サーバ３５０は物理計算機単位にインストールされても良いし、業務システム単位、テナント単位にインストールされても良い。インシデントの発生量や業務システムの規模を基にインストールすることにより効率的な監視が可能となる。
ログ監視部３０１は、ログ監視テーブル３１１から監視対象のログ情報を読み出し、特定の文字列がログに出力されると、インシデント生成部３１３を呼び出し、インシデントを生成する。生成されたインシデントは、送信部３０３にて情報集約サーバ１１に送信される。稼働データ監視部３０２は、稼働データ監視テーブル３１２から監視対象の稼働データ情報を読み出し、監視対象の稼働データ情報を取得する。取得された稼働データ情報は送信部３０３にて情報集約サーバ１１に送信される。また、取得した際に稼働データが閾値を超えていた場合は、インシデント生成部３１３を呼び出し、インシデントを生成し、送信部３０３にて情報集約サーバ１１にインシデントを送信する。ログ監視部３０１、稼働データ監視部３０２、送信部３０３等の処理部を含む監視サーバ３５０は主記憶領域３６０に格納されCPU１７で実行される。

図７は、業務サーバ３１が情報集約サーバ１１に送信するインシデント情報４００のテーブルと稼働データ情報４１０のテーブルを示す。図面ではスペースの問題で上下に分かれて記載されているが、本実施例では一つのテーブルとして実現された例で説明する。以下のテーブルの図面についても同様の表記である。インシデント情報４００は、テナントID４０１、インシデントグループ名４０２、インスタンスID４０３、重大度４０４、インシデント発生日時４０５、インシデント種別４０６、メッセージ４０７から構成される。テナントID４０１は、インシデントが発生した業務サーバが属するテナントのIDであり、各テナントを識別する。インシデントグループ名４０２は、インシデントが発生した業務サーバが属する業務システム２２の名称であり、同一テナント内の業務システム２２を識別する。インスタンスID４０３は、インシデントが発生した業務サーバの名称であり、同一業務システム２２内の業務サーバを識別する。重大度４０４は、発生したインシデントの重大度を示し、「Error」、「Warning」の2種類のいずれかが入力される。インシデント種別４０６は、インシデントの種類を示し、運用者によって自由に定義可能である。メッセージ４０７は、インシデントの内容を示す。稼働データ情報４１０は、テナントID４１１、インシデントグループ名４１２、インスタンスID４１３、取得日時４１４、稼働データ４１５から構成される。取得日時は稼働データ４１５を取得した日時であり、稼働データ４１５は、システム運用者によって指定された取得対象の稼働データ分だけ付加される。

図８は、情報集約サーバ１１が有するシステム情報テーブル１２１とインシデント対応テーブル１２２のデータ構成を示す。システム情報テーブル１２１とインシデント対応テーブル１２２は、優先度判定部１１１がインシデントの優先度を定義するために読み出されるテーブルである。システム情報テーブル１２１は、テナントID５０１、インシデントグループ名５０２、業務機能５０３、サービス稼働率５０４、サービスコアタイム５０５から構成される。業務機能５０３は、業務システム２２内で稼働する業務機能の名称であり、サービス稼働率５０４は業務機能５０３のサービス稼働率を示す。サービスコアタイム５０５は業務機能５０３が最も利用される時間帯といったインシデントが発生した際に当該業務機能への影響度が大きい期間を示す。インシデント対応テーブル１２２は、テナントID５１１、インシデントグループ名５１２、インスタンスID５１３、メッセージ５１４、復旧リミット時間５１５、復旧作業時間５１６、業務機能５１７から構成される。復旧リミット時間５１５は、該当するインシデントを復旧しなければならいリミット時間を示し、復旧作業時間５１６は、そのインシデントに対する復旧作業に要する時間を示す。インシデントが発生した際には、優先度判定部１１１がインシデント情報４００のテナントID４０１、インシデントグループ名４０２、インスタンスID４０３、メッセージ４０７と合致するか比較し、発生したインシデントがインシデント対応テーブル１２２に情報が登録されているかを確認する。

図９は、情報集約サーバ１１が有する優先度付きインシデント情報テーブル１２５のデータ構成を示す。優先度付きインシデント情報テーブル１２５は、テナントID５２１、インシデントグループ名５２２、業務機能５２３、優先度５２４、インスタンスID５２５、重大度５２６、インシデント発生日時５２７、インシデント種別５２８、メッセージ５２９、復旧リミット時間５３０、復旧作業時間５１６から構成される。インシデントが発生すると、優先度判定部１１１で優先度が定義され、インシデント登録部１１２にて優先度付きインシデント情報テーブル１２５にインシデント情報が登録される。また、ナビゲーションサーバ１２から定期的に情報が取得される。取得されたレコードは削除される。

図１０は、情報集約サーバ１１が有する稼働データ情報テーブル１２３と重要稼働データテーブル１２４のデータ構成を示す。稼働データ情報テーブル１２３は、テナントID５４１、インシデントグループ名５４２、インスタンスID５４３、取得日時５４４、稼働データ５４５から構成される。情報集約サーバ１１は、業務サーバ３１から受信した稼働データ情報４１０をそのまま稼働データ情報テーブル１２３に登録する。重要稼働データテーブル１２４は、テナントID５５１、インシデントグループ名５５２、インスタンスID５５３、重要稼働データ５５４から構成される。重要稼働データ５５４は、業務サーバ３１上で取得している複数ある稼働データ３２３の中で最も重要となる稼働データを運用者によって２つ以上で最大４つまで登録することが可能である。２つのテーブルは、ともにインシデントが発生した際に、優先度判定部１１１にて優先度を定義する際に読み出されるテーブルである。

図１１は、ナビゲーションサーバ１２が有するインシデント情報表示テーブル２２２のデータ構成例を示す。インシデント情報表示テーブル２２２は、テナントID６０１、インシデントグループ名６０２、業務機能６０３、優先度６０４、インスタンスID６０５、インシデントID６０６、重大度６０７、インシデント発生日時６０８、インシデント種別６０９、メッセージ６１０、復旧リミット時間６１１、復旧作業時間６１２、基盤情報６１３、センタ情報６１４から構成される。インシデント情報表示テーブル２２２は、ユーザからインシデント一覧表示のリクエストが来た際に、インシデント表示部２１４から読み出されるテーブルである。インシデントID６０６は、優先度付きインシデント登録部２１２がインシデント情報表示テーブル２２２にインシデントを登録する際に生成されるインシデントを識別するIDである。基盤情報６１３は、業務サーバ３１が稼働しているクラウドシステムの名称やオンプレ環境かを示し、センタ情報６１４は、業務サーバ３１が稼働しているセンタの場所を示す。

図１２は、ナビゲーションサーバ１２が有するシステム基盤情報テーブル２２１とインシデント対応履歴テーブル２２３のデータ構成例を示す。システム基盤情報テーブル２２１は、テナントID６２１、インシデントグループ名６２２、インスタンスID６２３、基盤情報６２４、センタ情報６２５から構成され、予め運用担当者によって情報が登録されるテーブルである。また、システム基盤情報テーブル２２１は、優先度付きインシデント登録部２１２がインシデント情報表示テーブル２２２にインシデントを登録する際に呼び出され、該当する基盤情報６２４、センタ情報６２５の情報がインシデントに付加される。インシデント対応履歴テーブル２２３は、テナントID６３１、インシデントグループ名６３２、インスタンスID６３３、インシデントID６３４、ユーザ名６３５、ステータス６３６、登録日時６３７、対応履歴６３８から構成される。インシデント対応履歴テーブル２２３は、インシデント発生時に新規レコードが作成され、ステータス６３６は「open」、ユーザ名６３５、対応履歴６３８は何も情報を入力せずに登録される。ユーザが情報を更新する際に、ユーザ名６３５には情報を入力したユーザ名が入り、ステータス６３６には対応内容に応じて「going」、「close」のいずれかが入力され、対応履歴６３８にはインシデントの対応内容が入力される。
図１３は、ナビゲーションサーバ１２が有するエスカレーション情報テーブル２２４のデータ構成を示す。エスカレーション情報テーブル２２４は、テナントID６４１、インシデントグループ名６４２、インスタンスID６４３、基盤情報６４４、センタ情報６４５、連絡先６４６から構成される。連絡先６４６は複数指定することができ、運用者によって自由に登録するこが可能である。エスカレーション情報テーブル２２４は、インシデント発生時にインシデントに対応する通知先として情報が読み出される。また、業務サーバ３１が別クラウドシステムに移行した際には、移行先のクラウドシステムの情報に基盤情報６４４、センタ情報６４５、連絡先６４６が更新される。

図１４は、ナビゲーションサーバ１２が表示するインシデント一覧７００の画面を示す。画面構成は優先度の高いインシデントを表示する「重要インシデント７１１」一覧を上部に、優先度の低いインシデントを表示する「インシデント７１２」一覧を下部に配置し、優先度によって一覧表示を区別した画面構成である。それぞれの一覧には、インシデント情報表示テーブル２２２から読み出された復旧リミット時間６１１、復旧作業時間６１２と現在時刻をもとに算出する「残り時間」の情報が表示され、「残り時間」が小さい順にインシデントが表示される。復旧リミット時間６１１が登録されていないインシデントは「残り時間」には「-」が表示される。また、「インシデント７１２」一覧で表示されているインシデントは、「残り時間」が時間の経過とともに小さくなっていき、3時間以下になると優先度が「高」に変更され、「重要インシデント７１１」一覧側で表示される。また、任意の文字列を入力して特定のインシデントのみ抽出可能な検索機能も有している。

図１５は、ナビゲーションサーバ１２が表示するインシデント詳細表示７２０の画面を示す。インシデント詳細表示７２０は、インシデント一覧７００で表示されているインシデントを一つ選択し、選択した状態でインシデント詳細表示７０１のボタンをクリックした際の遷移先の画面である。画面は、インシデント一覧７００では表示されない「基盤情報」や「センタ情報」、インシデントの影響を受ける「業務機能」などの情報をインシデント情報表示テーブル２２２から読み出し表示する構成となっている。

図１６は、監視サーバの動作を示すフローチャートである。

ステップ８０１：稼働データ監視部３０２は、稼働データ監視テーブル３１２から監視対象の稼働データと閾値の情報を読み出し、該当する稼働データ３２３の数値を取得する。

ステップ８０２：稼働データ監視部３０２は、取得した数値と閾値を比較し、閾値を超えていた場合は、ステップ８０５へ移る。

ステップ８０３：稼働データ監視部３０２は、送信部３０３を呼び出し、取得した稼働データ３２３から稼働データ情報４１０を生成し、情報集約サーバ１１に送信する。

ステップ８０４：稼働データ監視部３０２は、定義された監視間隔だけ待機し、ステップ８０１に戻る。

ステップ８０５：稼働データ監視部３０２は、インシデント生成部３１３を呼び出し、インシデント情報４００を生成する。ステップ８０６：稼働データ監視部３０２は、送信部３０３を呼び出し、生成したインシデント情報４００を情報集約サーバ１１に送信し、ステップ８０３に移る。

図１７は、監視サーバ３５０のログ監視の動作を示すフローチャートである。

ステップ８１１：ログ監視部３０１は、ログ監視テーブル３１３から監視対象のログと監視文字列の情報を読み出し、該当するOSイベントログ３２１や業務ログ３２２の情報を取得する。

ステップ８１２：ログ監視部３０１は、取得したログ情報が更新されているか確認し、更新されていいなかった場合は、ステップ８１６へ移る。

ステップ８１３：ログ監視部３０１は、取得したログ情報と監視文字列が一致するか比較し、一致しない場合は、ステップ８１６へ移る。

ステップ８１４：ログ監視部３０１は、インシデント生成部３１３を呼び出し、インシデント情報４００を生成する。
ステップ８１５：ログ監視部３０１は、送信部３０３を呼び出し、生成したインシデント情報４００を情報集約サーバ１１に送信する。

ステップ８１６：ログ監視部３０１は、定義された監視間隔だけ待機し、ステップ８１１に戻る。

次に、情報集約サーバ１１の処理について説明する。情報集約サーバ１１は受信部１０１経由で監視サーバ３５０から送信された稼働データやインシデント情報を受信し、稼働データ登録部１１３が稼働データ情報テーブル１２３へ登録する。情報集約サーバ１１が受け持つ全ての監視サーバ３５０からの情報を受け取り、受け取った稼働データやインシデント情報をマージして保管する。

図１８は、情報集約サーバ１１がインシデントに優先度を定義する動作を示すフローチャートである。

ステップ８２１：情報集約サーバ１１は、監視サーバ３５０から送信されたインシデント情報４００を受信部１０１から受信する。

ステップ８２２：優先度判定部１１１は、インシデント対応テーブル１２２を読み出し、受信したインシデント情報４００が、インシデント対応テーブル１２２に登録されているインシデントか比較する。

ステップ８２３：インシデント情報４００がインシデント対応テーブル１２２に登録されていなかった場合は、ステップ８３０に移る。

ステップ８２４：優先度判定部１１１は、インシデント対応テーブル１２２から該当する業務機能５１７の情報を抽出し、インシデント情報４００に付加する。

ステップ８２５：優先度判定部１１１は、インシデント対応テーブル１２２から該当する復旧リミット時間５１５を読み出し、復旧リミット時間５１５が登録されていない場合は、ステップ８３１に移る。

ステップ８２６：優先度判定部１１１は、インシデント対応テーブル１２２から該当する復旧リミット時間５１５、復旧作業時間５１６を抽出し、インシデント情報４００に付加する。

ステップ８２７：抽出した復旧リミット時間５１５が3時間を超える場合は、ステップ８３１に移る。

ステップ８２８：優先度判定部１１１は、インシデント情報４００に優先度情報「高」を付加する。

ステップ８２９：優先度判定部１１１は、インシデント登録部１１２を呼び出し、インシデント情報４００を優先度付きインシデント情報テーブル１２５に登録する。

ステップ８３０：優先度判定部１１１は、インシデント情報４００に優先度情報「低」を付加し、ステップ８２９に移る。

図１９は、情報集約サーバ１１がインシデントに優先度を定義する動作を示すフローチャートである。

ステップ８４１：優先度判定部１１１は、システム情報テーブル１２１から、インシデント情報４００のテナントID４０１、インシデントグループ名４０２、ステップ８２４でインシデント情報４００に付加した業務機能５１７が一致するレコードを読み出し、該当するレコードのサービス稼働率５０４の情報を取得する。

ステップ８４２：サービス稼働率５０４が99.7％以上の場合、ステップ８４８に移る。

ステップ８４３：優先度判定部１１１は、ステップ８４１で読み出したレコードのサービスコアタイム５０５の情報を取得する。

ステップ８４４：優先度判定部１１１は、重要稼働データテーブル１２４から、インシデント情報４００のテナントID４０１、インシデントグループ名４０２、インスタンスID４０３と一致するレコードを読み出し、該当するレコードの重要稼働データ５５４の情報を取得する。優先度判定部１１１は、さらに稼働データテーブル１２３から、インシデント情報４００のテナントID４０１、インシデントグループ名４０２、インスタンスID４０３と一致するレコードを読み出し、重要稼働データ５５４と一致する稼働データ５４５を取得する。

ステップ８４５：インシデント情報４００のインシデント発生日時４０５が、ステップ８４２で取得したサービスコアタイム５０５内であり、かつステップ８４４で取得した稼働データ５４５の内、閾値を超過したデータが2つ以上ある場合は、ステップ８４８へ移る。

ステップ８４６：優先度判定部１１１は、インシデント情報４００に優先度情報「低」を付加することによりインシデントの優先順位を下げることが可能となる。

ステップ８４７：優先度判定部１１１は、インシデント登録部１１２を呼び出し、インシデント情報４００を優先度付きインシデント情報テーブル１２５に登録する。登録されたインシデント情報は集められた複数のクラウドシステムのインシデント情報がマージされているため、このクラウド管理システムが管理しているシステム内で発生しているインシデントのうち、最も優先度の高いインシデントから出力していくことが可能となる。

ステップ８４８：優先度判定部１１１は、インシデント情報４００に優先度情報「高」を付加し、ステップ８４７に移る。

図２０は、ナビゲーションサーバ１２がインシデントを取得・登録する動作のフローチャートである。

ステップ８６１：ナビゲーションサーバ１２は、インシデント取得部２１１から情報集約サーバ１１に接続する。

ステップ８６２：インシデント取得部２１１は、情報集約サーバ１１の優先度付きインシデント情報テーブル１２５から未取得のインシデント情報を取得する。

ステップ８６３：優先度付きインシデント登録部２１２は、取得したインシデント情報とシステム基盤情報テーブル２２１のテナントID６２１、インシデントグループ名６２２、インスタンスID６２３を比較し、一致するレコードを読み出し、該当するレコードの基盤情報６２４、センタ情報６２５の情報を取得する。

ステップ８６４：優先度付きインシデント登録部２１２は、基盤情報６２４、センタ情報６２５を取得したインシデント情報に付加する。

ステップ８６５：優先度付きインシデント登録部２１２は、インシデントを識別するインシデントIDを生成し、インシデント情報に付加する。

ステップ８６６：インシデント対応履歴登録部２１３は、インシデント対応履歴テーブル２２３に新規レコードを追加し、テナントID６３１、インシデントグループ名６３２、インスタンスID、インシデントIDにはインシデント情報を入力する。ステータス６３６には「open」を入力し、ユーザ名６３５、対応内容６３７には何も入力しない。

ステップ８６７：優先度付きインシデント登録部２１２は、インシデント情報をインシデント情報表示テーブル２２２に登録する。

ステップ８６８：インシデント取得部２１１は、情報集約サーバ１１の優先度付きインシデント情報テーブル１２５のインシデント情報を全て取得していない場合は、ステップ８６２に移る。

ステップ８６９：インシデント取得部２１１は、定義された監視間隔だけ待機し、ステップ８６１に移る。

図２１は、ナビゲーションサーバ１２がインシデント一覧画面７００を表示する動作のフローチャートである。

ステップ８８１：ナビゲーションサーバ１２は、ユーザからインシデント一覧画面７００の要求を受け付ける。

ステップ８８２：ナビゲーションサーバ１２のインシデント表示部２１４は、インシデント情報表示テーブル２２２からインシデント情報を取得する。

ステップ８８３：インシデント表示部２１４は、取得したインシデント情報の復旧リミット時間６１１が登録されていない場合は、ステップ８８９に移る。

ステップ８８４：インシデント表示部２１４は、（インシデント発生日時６０８＋復旧リミット時間６１１）−(現在時刻＋復旧作業時間６１２)で「残り時間」を算出する。

ステップ８８５：インシデント情報の優先度６０４が「高」の場合は、ステップ８８７に移る。

ステップ８８６：ステップ８８４で算出した「残り時間」が3時間以下の場合は、ステップ８９０に移る。

ステップ８８７：インシデント表示部２１４は、「残り時間」の情報をインシデント情報に付加する。

ステップ８８８：インシデント表示部２１４は、インシデント対応履歴テーブル２２３からインシデントID６３４が一致するレコードのステータス６３６を読み出し、インシデント情報に付加する。

ステップ８８９：インシデント表示部２１４は、優先度に応じて、インシデント情報を
インシデント一覧画面７００に表示する。インシデントの発生している業務サーバと同じ物理計算機で稼働している他の業務サーバが有る場合には、当該業務サーバについてもインシデントの影響を受けることを示す情報をインシデント画面７００に追加しても良い。

ステップ８９０：インシデント表示部２１４は、インシデント情報の優先度を「高」に変更し、ステップ８８７に移る。

図２２は、業務サーバ３１が他クラウドシステムへ移行した時の動作のフローチャートである。

ステップ９０１：業務サーバ３１が他のクラウドシステムへ移行する。

ステップ９０２：業務サーバ３１は、送信部３０３から移行先クラウドシステム情報をナビゲーションサーバ１２に送信する。

ステップ９０３：ナビゲーションサーバ１２は、システム基盤情報登録部２１５を呼び出し、システム基盤情報テーブル２２１内の移行した業務サーバ３１に該当するレコードを読み出し、基盤情報６２４、センタ情報６２５を移行先クラウドシステム情報に更新する。

ステップ９０４：ナビゲーションサーバ１２は、メール送信部２１６を呼び出し、移行した業務サーバ３１から送信された移行先クラウドシステム情報から、エスカレーション情報テーブル２２４内でテナントID６４１、基盤情報６４４、センタ情報６４５と一致するレコードの連絡先６４６を取得する。

ステップ９０５：メール送信部２１６は、連絡先６４６へ業務サーバ３１が移行したことを通知する。

１０・・・クラウド管理システム、１１・・・情報集約サーバ、１２・・・ナビゲーションサーバ、１３・・・テナント、３１・・・業務サーバ、１０１・・・受信部、１０２・・ネットワークインタフェース部、１１１・・・優先度判定部、１１２・・・インシデント登録部、１１３・・・稼働データ登録部、１２１・・・システム情報テーブル、１２２・・・インシデント対応テーブル、１２３・・・稼働データ情報テーブル、１２４・・・重要稼働データテーブル、１２５・・・優先度付きインシデント情報テーブル、２０１・・・表示部、２１４・・・インシデント一覧表示部、２２２・・・インシデント情報表示テーブル、３０１・・・ログ監視部、３０２・・・稼働データ監視部、３２１・・・OSイベントログ、３２２・・・業務ログ、３２３・・・稼働データ、７００・・・インシデント一覧画面、７２０・・・インシデント詳細表示画面。

Claims

複数のクラウドシステムで稼働する仮想計算機上で動作する複数テナントの業務サーバのインシデントを管理するクラウド管理システムであって、
前記業務サーバからのインシデント情報を受信しマージするインシデント受信部と、
マージされたインシデント情報の種別と発生時刻に基づいてインシデントの前記複数のクラウドシステム内での優先度を求める優先度判定部と、
求められた優先度に従ってインシデント情報を出力する出力部を備えることを特徴とするクラウド管理システム。
業務サーバ毎にインシデントの種別と発生時刻に応じたインシデント優先度を記載した優先度情報を備え、
優先度判定部が優先度テーブルの情報に基づいて発生したインシデントの優先度を求めることを特徴とする請求項１に記載のクラウド管理システム。
業務サーバ毎の負荷を測定するサーバ負荷測定部を備え、
サーバ負荷測定部が測定した業務サーバ負荷が予め定められた値を超える時間帯は当該業務サーバのインシデント優先度を上げる優先度調整部を備えることを特徴とする請求項２に記載のクラウド管理システム。
業務サーバ毎の負荷を測定するサーバ負荷測定部を備え、
サーバ負荷測定部が測定した業務サーバ負荷が予め定められた値を下回った時間帯は当該業務サーバのインシデント優先度を下げる優先度調整部を備えることを特徴とする請求項２に記載のクラウド管理システム。
前記優先度情報はさらにインシデントに対応した復旧時間に関する情報を格納し、
出力部がインシデントと対応付けてインシデントの対応に必要な残り時間に関する情報を出力することを特徴とする請求項２−４のいずれか１項に記載のクラウド管理システム。
仮想計算機が他のクラウドシステムへ移動したとき、移動した仮想計算機で動作する業務サーバのインシデントに関する情報を移動元クラウドシステムから移動先クラウドシステムへ変更し、移動先クラウドシステムのインシデントとして出力することを特徴とする請求項４に記載のクラウド管理システム。
複数のクラウドシステムで稼働する仮想計算機上で動作する複数テナントの業務サーバのインシデントを管理するクラウド管理方法であって、
インシデント受信部が前記業務サーバからのインシデント情報を受信しマージし、
優先度判定部がマージされたインシデント情報の種別と発生時刻に基づいてインシデントの前記複数のクラウドシステム内での優先度を求め、
出力部が求められた優先度に従ってインシデント情報を出力する、ことを特徴とするクラウド管理方法。
業務サーバ毎にインシデントの種別と発生時刻に応じたインシデント優先度を記載した優先度情報を含み、
優先度判定部が優先度テーブルの情報に基づいて発生したインシデントの優先度を求めることを特徴とする請求項７に記載のクラウド管理方法。
サーバ負荷測定部が業務サーバ毎の負荷を測定し、
優先度調整部がサーバ負荷測定部が測定した業務サーバ負荷が予め定められた値を超える時間帯は当該業務サーバのインシデント優先度を上げることを特徴とする請求項８に記載のクラウド管理方法。
サーバ負荷測定部が業務サーバ毎の負荷を測定し、
優先度調整部はサーバ負荷測定部が測定した業務サーバ負荷が予め定められた値を下回った時間帯は当該業務サーバのインシデント優先度を下げることを特徴とする請求項８に記載のクラウド管理方法。
前記優先度情報はさらにインシデントに対応した復旧時間に関する情報を格納し、
出力部がインシデントと対応付けてインシデントの対応に必要な残り時間に関する情報を出力することを特徴とする請求項８−１０のいずれか１項に記載のクラウド管理方法。
仮想計算機が他のクラウドシステムへ移動したとき、移動した仮想計算機で動作する業務サーバのインシデントに関する情報を移動元クラウドシステムから移動先クラウドシステムへ変更し、出力部は移動先クラウドシステムのインシデントとしてインシデントを出力することを特徴とする請求項１０に記載のクラウド管理方法。