(57)【要約】【課題】コールドスタンバイ方式により冗長化されたコンピュータシステムにおいて、稼働系サーバの障害発生時における系切り替え時間を短縮するとともに、系切り替え中の予期しない系切り替え失敗を抑制する。【解決手段】複数の稼働系サーバとコールドスタンバイの待機系サーバから成る冗長化システムにおいて、該冗長化システムを管理する管理サーバは、前記複数の稼働系サーバに対して稼働状況を問合せ、各稼働系サーバからの応答に障害情報が含まれている場合に、障害種別対応のしきい値テーブルを参照して、前記待機系サーバをホットスタンバイに移行させる、又は系切り替えを実施する。【選択図】  図１
2016224490.tif 000002
【特許請求の範囲】
【請求項１】
複数の稼働系サーバとコールドスタンバイの待機系サーバから成る冗長化システムにおいて、該冗長化システムを管理する管理サーバは、前記複数の稼働系サーバに対して稼働状況を問合せ、各稼働系サーバからの応答に障害情報が含まれている場合に、障害種別対応のしきい値テーブルを参照して、前記待機系サーバをホットスタンバイに移行させる、又は系切り替えを実施することを特徴とする冗長化システム。
【請求項２】
前記管理サーバは、前記障害情報に含まれる障害種別対応に算出された値が前記しきい値テーブル内の第１のしきい値より大きく第２のしきい値より小さい場合に、前記待機系サーバをホットスタンバイに移行させ、前記値が前記第２のしきい値より大きい場合に、系切り替えを実施することを特徴とする請求項１に記載の冗長化システム。
【請求項３】
前記管理サーバは、第１の稼働系サーバからの応答により前記待機系サーバを前記第１の稼働系サーバのＯＳ（以下、第１のＯＳ）が稼働するホットスタンバイに移行させた後、第２の稼働系サーバからの応答により前記待機系サーバを前記第２の稼働系サーバのＯＳ（以下、第２のＯＳ）が稼働するホットスタンバイに移行させる必要が生じた場合に、前記待機系サーバで稼働するＯＳとして前記第１のＯＳ又は前記第２のＯＳのいずれのＯＳを稼働させるかを決定することを特徴とする請求項１又は２に記載の冗長化システム。
【請求項４】
前記管理サーバは、前記複数の稼働系サーバの重要度を示す重要度テーブルを参照して、重要度が最も高い稼働系サーバのＯＳを前記待機系サーバで稼働させることを特徴とする請求項３に記載の冗長化システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、冗長化されたコンピュータシステムの系切り替えに関するものである。
【背景技術】
【０００２】
今日の社会では、コンピュータを使用する情報システムは必要不可欠なものとなっている。中でも、公共分野、金融分野において利用されるシステムには、高い可用性が要求されており、システムが停止しないこと、万一停止する事態に陥った場合でも、迅速に復旧できることが要求されている。
【０００３】
このような高可用性を実現するための技術として、サーバの冗長化構成をとる方法がある。この方法では、通常時に業務を行う稼働系サーバと別に、待機系サーバを準備する。
待機系サーバは通常時は業務を行わない。稼働系サーバにおいて業務の継続が不可能となった場合に、待機系サーバがその業務を引き継いで動作することで、システム全体としての業務不稼働時間を最小限に抑える。
【０００４】
冗長化構成の実現方法として、稼働系サーバと待機系サーバを1対1で対応させる構成方法や、複数の稼働系サーバに対し1台の待機系サーバを用意するＮ対１構成が考えられる。冗長化構成では、あらかじめ障害に備え、待機系サーバで稼働系サーバと同等のソフトウェアを動作させておき、稼働系サーバで障害が発生した場合には即座に系切り替えを行い待機系サーバで稼働系サーバの業務を引き継ぐホットスタンバイのほか、特許文献１にあるように待機系サーバは停止させておき、稼働系サーバで障害が発生した場合に待機系サーバを起動し、待機系サーバの起動が完了した後に系切り替えを行い稼働系サーバの業務を引き継ぐコールドスタンバイなどの構成がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−３５１１
【特許文献２】特開２０１０−２７８２７７
【発明の概要】
【発明が解決しようとする課題】
【０００６】
冗長化システムの目的は、業務の不稼働時間を可能な限り短縮することにある。この場合に問題となるのが、系切り替え時間の増大、あるいは系切り替えの失敗である。コールドスタンバイでは、障害発生後にサーバ起動を行うため、起動完了までの間、系切り替えが完了できず、一定の不稼働時間が発生してしまう。ホットスタンバイでは起動のための待ち時間は発生しないものの、待機のために電力を消費してしまう。これに対し、特許文献２において、通常はコールドスタンバイとしておき、障害の予兆がある場合にはホットスタンバイとする手法が提案されているが、この手法は複数の稼働系サーバに対し1台の待機系サーバを持つようなＮ対１の冗長化を取るシステムには適用できず、予兆を検出した際の振る舞いもホットスタンバイへの移行のみであり、障害の予兆の重大性によっては実際に系切り替えを行う、といった、柔軟な対応を取ることが不可能である。
【課題を解決するための手段】
【０００７】
複数の稼働系サーバとコールドスタンバイの待機系サーバから成る冗長化システムにおいて、該冗長化システムを管理する管理サーバは、前記複数の稼働系サーバに対して稼働状況を問合せ、各稼働系サーバからの応答に障害情報が含まれている場合に、障害種別対応のしきい値テーブルを参照して、前記待機系サーバをホットスタンバイに移行させる、又は系切り替えを実施する。
【発明の効果】
【０００８】
本発明では、Ｎ対１のような冗長化システムにおいても、待機系サーバ上で、障害の予兆と業務の重要度に応じて、最も重要度の高いサーバに対してホットスタンバイ状態になることが可能となり、業務不稼働時間を短縮できる。また、稼働系サーバがまだ正常動作可能な状況下で系切り替えを実施することが可能になるため、稼働系サーバの停止失敗のリスクを最小限に抑えることが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本発明の全体構成の概略を表すブロック図である。
【図２】サーバ監視の流れを表す動作フローである。
【図３】待機系サーバをホットスタンバイ状態に移行する際の流れを示す動作フローである。
【図４】系切り替えを実施する際の流れを示す動作フローである。
【図５】系切り替えプログラムが収集する障害情報の例を示す図である。
【図６】系切り替えプログラムがホットスタンバイへの移行を制御する際に使用するしきい値テーブルの例を示す図である。
【図７】系切り替えプログラムがホットスタンバイへ移行する業務の重要度を判断する際に参照する重要度テーブルの例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態を、図を用いて説明する。
【００１１】
図1は、本発明の実施例におけるハードウェアの構成を表すブロック図である。この図に示されるシステムは、2台の稼働系サーバ１０１、１１１と、1台の待機系サーバ１２１、サーバ外部にあるディスク装置１３１、システム全体の管理を行うための管理サーバ１４１からなる。稼働系サーバ１０１、１１１と待機系サーバ１２１は、それぞれサービスプロセッサ１０３、１１３、および１２３を有している。サービスプロセッサはサーバ自身のハードウェアを監視し、状況をＳＶＰログ１０８，１１８，１２８に記録する。また、系切り替えプログラム１４２からの指示に応じて、ハードウェアの起動や停止を制御する能力を持つ。サービスプロセッサはＯＳや業務プログラムが使用するものと異なるリソースを使用するため、サーバ上の業務稼働状況に依存せず動作が可能である。
【００１２】
稼働系サーバ上ではそれぞれＯＳ１０２、１１２が動作しており、その上で監視プログラム１０５、１１５および業務プログラム１０６、１１６が動作している。ＯＳは、ＯＳ自身の動作状況や業務プログラムの動作をＯＳログ１０７、１１７に記録する。監視プログラムは業務プログラムの動作状況を監視するほか、ＯＳログの収集を行い、状況を系切り替えプログラム１４２に送信する。また、系切り替えが必要な場合には、系切り替えプログラム１４２からの指示に応じて、業務プログラムの停止やＯＳのシャットダウンを実行する能力がある。また、それぞれのサーバはＬＡＮアダプタ１０４１および、１０４２、１１４１および１１４２、１２４１および１２４２を有する。系切り替えプログラム１４２は監視ネットワーク１５１を介して、サービスプロセッサおよび監視プログラムと通信することができる。また、それぞれのＯＳおよび業務プログラムは、業務ネットワーク１５２を経由してＯＳ間、あるいは外部と通信することができる。
【００１３】
なお、本発明における稼働系サーバ数は２に制限されるものではなく、３、あるいはそれ以上の稼働系サーバを含んでも良い。また、管理サーバ１４１も、管理サーバ自身の障害に備えて冗長化構成を採ることが可能である。平常時、待機系サーバ１２１は停止状態にある。待機系サーバ１２１は稼働系サーバ１０１および１１１と同等のＣＰＵ、メモリ、ＩＯを有し、起動後はＯＳ１０２またはＯＳ１１２のどちらか、また、業務プログラム１０６、１１６のいずれかを動作させるのに十分な性能がある。
【００１４】
管理サーバ１４１上では、系切り替えプログラム１４２が稼働している。系切り替えプログラム１４２は、監視プログラム１０５、１１５およびサービスプロセッサ１０３，１１３から障害の予兆を収集し、その必要があると判断した場合にはサービスプロセッサや監視プログラムに対し、待機系サーバをホットスタンバイ状態に移行させる、あるいは系切り替え実行の指示を行う。系切り替えプログラム１４２はこれら系切り替えの要否を判断するための情報として、しきい値テーブル１４３、重要度テーブル１４４を保持する。系切り替えプログラム１４２が収集する障害の予兆の例としては、ハードウェア障害の予兆に関するものとしては、メモリの訂正可能エラーの発生や、電源の供給電圧の変動、通信用アダプタの応答遅延、冷却ファンの回転速度異常などが挙げられる。ソフトウェア障害の予兆に関するものとしては、メモリスワップの頻発や、ＣＰＵ負荷の高騰、業務プログラムが生成した子プロセスやオープンしたファイル数、その他出力するエラーログの内容などが挙げられる。なお、可能であれば、サービスプロセッサからソフトウェア障害の予兆を、監視プログラムからハードウェア障害の予兆を収集してもよい。
【００１５】
図２は、本構成における管理サーバ１４１の系切り替えプログラム１４２の動作フローである。
【００１６】
系切り替えプログラム１４２は、ステップ２０１において、事前に設定されたスケジュール、あるいは前回の起動時からの経過時間に従って起動される。起動後は、ステップ２０２において監視プログラム１０５、１１５、サービスプロセッサ１０３、１１３に対して、障害の予兆の発生の有無を問い合わせ、ステップ２０３において一定時間応答を待つ。時間内にいずれかの問い合わせ先から応答がなかった場合、ステップ２０４に進んで系切り替え処理を実行する。ステップ２０４で実施する系切り替え処理の内容を図３に示すが、詳細は後述する。
【００１７】
ステップ２０３において、サービスプロセッサ１０３、１１３、監視プログラム１０５、１１５は、それぞれ障害の予兆が何も発生していなければ、異常がない旨を系切り替えプログラム１４２に応答する。また、何らかの障害の予兆が発生していた場合、図５に示す障害情報を含む応答を返す。障害情報は、発生時刻を表す日時５０１、その予兆の種別に加え、予兆の発生したサーバがどれかを示す事象コード５０２、その予兆の内容を表す詳細情報５０３、その障害の予兆の重大性を示すスコア５０４を含む。
【００１８】
スコア５０４の算出方法は、障害の種別ごとに異なる。外部からの供給電圧の瞬間的な変動や、メモリの訂正可能エラーの発生は、発生頻度が高いほど症状が重く、実障害に進展する可能性が高いものであるから、例えば、過去２４時間の間に同事象が発生した回数をスコアとして算出する。
【００１９】
また、メモリ空き容量の減少や、ＣＰＵ使用率の高騰などは、その状態が継続した時間をスコアとして算出する。ＩＯの応答遅延であれば、遅延時間がある許容値を超えたとき、その超えた時間をスコアとして算出する。
【００２０】
系切り替えプログラム１４２は、ステップ２０５でそれぞれの応答が障害情報を含んでいるかを確認する。障害情報がいずれの応答にも含まれていない場合は、問題なしとして、ステップ２１０に進み、プログラムを終了する。
【００２１】
系切り替えプログラム１４２が障害情報を受け取った場合は、ステップ２０６でその障害情報を、管理サーバ１４１が持つしきい値テーブル１４３、重要度テーブル１４４の情報と比較する。
【００２２】
図６は、しきい値テーブル１４３の例を示す。事象コード６０１、影響部位６０２、起動しきい値６０３、系切り替えしきい値６０４からなる。
【００２３】
図７は、重要度テーブル１４４の例を示す。サーバＩＤ７０１と重要度７０２からなる。
【００２４】
管理サーバ１４１は収集した障害情報の事象コード５０２と一致するエントリをしきい値テーブル１４３から探す。また、障害の予兆のあったサーバと一致するサーバＩＤを重要度テーブル１４４から探す。次に、障害情報のスコア５０４に、該当するサーバＩＤの重要度７０２を乗じて、新たなスコアを算出し、算出された新たなスコアと起動しきい値６０３を比較する。なお、一度に複数の障害情報を受け取った場合は、それぞれのエントリに対し、ステップ２０６の上記処理を実施する。
【００２５】
このスコアが起動しきい値６０３を超えているエントリがある場合は、障害の予兆が見つかったと判断し、ステップ２０７で、スコアを系切り替えしきい値６０４と比較する。スコアが系切り替えしきい値６０４も超えている場合は、ステップ２０９で系切り替えを実施する。起動しきい値６０３を超えているが、系切り替えしきい値６０４は超えていない場合は、ステップ２０８で待機系サーバ１２１をホットスタンバイ状態に移行させる。
【００２６】
図4は、ステップ２０８の処理内容を示す詳細動作フローである。ステップ４０２で待機系サーバ１２１が起動しているかサービスプロセッサ1２３に確認する。待機系サーバ１２１が停止状態であればステップ４０６に進み、サービスプロセッサ１２３に待機系サーバ１２１で必要なＯＳを起動し、業務プログラムを稼働させるように指示する。既に待機系サーバが起動している場合は、ステップ４０３に進んで、待機系サーバで動作しているＯＳ、業務プログラムが障害の予兆を検知したサーバの業務を引き継げるか確認する。例えば、以前に稼働系サーバ１１１の予兆を検知した場合、待機系サーバ１２１は、業務プログラム１１６を引き継げるＯＳ、業務プログラムが起動するホットスタンバイ状態になっている。この時、稼働系サーバ１０１の監視プログラム１０５でも障害の予兆が見つかった場合、待機系サーバ１２１で稼働系サーバ１０１の業務プログラム１０６を引き継ぐことができない。この場合はステップ４０４に進む。
【００２７】
ステップ４０４では、今回障害の予兆を検出したサーバの業務と、以前に予兆を検出してホットスタンバイ状態になったサーバの業務、どちらを優先するか決定する。決定方法として、例えば重要度テーブル１４４の重要度が最も高いサーバの業務を引き継ぐようにする、といった判断や、障害の予兆のスコアが系切り替えしきい値に最も近いサーバの業務を引き継ぐようにする、といった判断を行う。頻繁に待機系サーバ上のＯＳ、業務プログラムが切り替わる事態を抑制するため、現在待機系サーバで起動している業務にはより高い優先度を与えても良い。
【００２８】
なお、実際の障害の発生を検出した場合や、スコアが系切り替えしきい値を超えた場合は、当然障害の発生した業務を最優先とする。判断の結果、現在待機系サーバで起動している業務が優先される場合は、何もせずステップ４０７に進んで終了する。
【００２９】
一方、今回障害の予兆、あるいは実際の障害が見つかった業務が優先される場合、ステップ４０５で待機系サーバを停止するよう監視プログラムにＯＳシャットダウンを指示する。その後、ステップ４０６で待機系サーバのサービスプロセッサに今回の業務に対応するＯＳ、業務プログラムを起動するよう指示する。
【００３０】
図３は、ステップ２０９の系切り替え動作を示す詳細動作フローである。なお、この系切り替え動作はステップ２０４の系切り替え動作と同等である。ステップ３０２で待機系サーバをホットスタンバイ状態にする。この処理は図4の内容と同等である。次に、ステップ３０３で、稼働系サーバの監視プログラムが系切り替えプログラムからの指示を処理できるか確認する。応答が無いなどの場合には、ステップ３０４で、稼働系サーバのサービスプロセッサにサーバの停止を指示する。監視プログラムが指示を処理できる場合は、ステップ３０５で系切り替え準備を指示する。具体的には、マウントしているディスク装置１３１のアンマウントや、ＬＡＮアダプタ１０４２、１１４２に割り付けられているＩＰアドレスのエイリアスを削除する、といった作業を行う。次に、ステップ３０６で稼働系サーバの監視プログラムに業務プログラムの停止、ＯＳシャットダウンを指示する。
【００３１】
稼働系サーバの停止を確認したら、ステップ３０７で待機系サーバの系切り替え準備を行う。ディスク装置のマウントや、ＩＰアドレスのエイリアス設定などが含まれる。全ての準備が完了したら、ステップ３０８に進んで、待機系サーバで業務を引き継ぐ。
【符号の説明】
【００３２】
１０１、１１１：稼働系サーバ
１０２、１１２：ＯＳ
１０３、１１３、１２３：サービスプロセッサ
１０４１、１０４２、１１４１、１１４２、１２４１、１２４２、１４５：ＬＡＮアダプタ
１０５、１１５：監視プログラム
１０６、１１６：業務プログラム
１０７、１１７：ＯＳログ
１０８、１１８、１２８：ＳＶＰログ
１３１：ディスク装置
１４１：管理サーバ
１４２：系切り替えプログラム
１４３：しきい値テーブル
１４４：重要度テーブル
１５１：監視ネットワーク
１５２：業務ネットワーク
５０１：日時
５０２、６０１：事象コード
５０３：詳細情報
５０４：スコア
６０２：影響部位
６０３：起動しきい値
６０４：系切り替えしきい値
７０１：サーバＩＤ
７０２：重要度
【図１】
2016224490.tif 000003
【図２】
2016224490.tif 000004
【図３】
2016224490.tif 000005
【図４】
2016224490.tif 000006
【図５】
2016224490.tif 000007
【図６】
2016224490.tif 000008
【図７】
2016224490.tif 000009