JP2007280155A

JP2007280155A - 分散システムにおける信頼性向上方法

Info

Publication number: JP2007280155A
Application number: JP2006107069A
Authority: JP
Inventors: Korin Ozaki; 光倫小▲崎▼
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-04-10
Filing date: 2006-04-10
Publication date: 2007-10-25

Abstract

【課題】
一件のトランザクションの処理遅延が業務に非常に大きな影響を及ぼすミッションクリティカル分野の情報処理業務システムにおいて、業務システムに障害が発生した場合の被害拡大は極めて大きいが、致命的な障害の発生や、障害に至る不安定な状態となったサーバに対してトランザクションが到達し続けることにより、影響が拡大する問題があった。
【解決手段】
本発明では、サーバに障害発生時もしくは障害に至る前の段階で、稼動中の各サーバのミドルウェアやオペレーティングシステムの出力する異常メッセージや、各サーバの各種リソース情報といった稼働情報を収集、分析することで、サービスの継続が不適当と判断される場合には即座にサーバを停止することでシステムの影響拡大を防止する方式を提示している。これにより、サーバでの障害発生時の影響拡大の防止が可能となる。
【選択図】図2

Description

本発明は、所定の処理を複数のコンピュータ装置で分散・連携して実行する分散システムに関する。その中でも、特にある装置で障害が発生した場合の回復のための技術に関する。すなわち、クライアント・サーバ方式等の分散系システムを、基幹業務等のミッションクリティカル分野に適用するに当たり要求されるシステム信頼性向上のための技術に関する。

所定の処理を複数の装置で、処理を実行する場合、ある装置で障害が発生するとその影響はシステム全体に及び処理全体が停止するとの問題があった。この障害を回復するための技術として、複数のサーバで冗長化構成を採り、あるサーバで障害が発生した場合でも、残りのサーバで業務（処理）を継続することが特許文献1および2に記載されている。
特許文献1においては、ネームサーバー制御方式として、ネームサーバーの一つが障害でダウンしても、ネットワークシステムを継続的に使用可能とするために、共用資源を登録するテーブルを有するネームサーバーを複数台用意しておき、ネームサーバー1がダウンしても、ネームサーバー2が機能することにより、システムダウンを回避する方式が開示されている。

また、特許文献2においては、障害が発生したサーバが行っていた処理を継続する代替サーバのロケーションの検索オーバヘッドを削減することを目的としている。このために、現用系サーバの障害時には、該サーバを利用している前記クライアントに、新たな現用系サーバのロケーションを通知する障害監視手段を有し、前記クライアントは、その通知が行われた際に、該サーバのロケーションを更新する手段を有することが開示されている。

特開平5−75637号公報特開2000−99483号公報

上記の特許文献1および2によれば、いずれもシステム信頼性向上施策として複数台のサーバによる冗長化構成を採り、単一サーバに障害が発生した場合でも、残りのサーバで業務処理を継続することでシステムの信頼性を確保している。

しかしながら、致命的な障害の発生や、障害に至る不安定な状態となったサーバに対してトランザクションが到達し続けることにより、影響が拡大する問題があった。すなわち、特許文献1および2のいずれも、障害が発生したサーバの代替サーバを用いることしか開示されておらず、代替サーバへの切り替え（含む検索）処理にどうしても時間がかかり、影響が拡大してしまう。

そこで、本発明では、サーバに障害発生時もしくは障害に至る前の段階など所定の状況を検知した場合、障害サーバをシステムから切り離す「切り離し処理」等により、システムの影響拡大を防止する。「切り離し処理」とは、例えば3台のサーバで構成される冗長化構成を有するシステムにおいて、1台のサーバを冗長化構成から離脱させ残りの2台のサーバでサービスを継続するための処理である。具体的には、稼動中の各サーバのミドルウェアやオペレーティングシステムの出力する異常メッセージや、各サーバの各種リソース情報といった稼働情報を収集する。稼働情報より、当該サーバの稼働を継続すべきか否かを稼働分析システムにおいて判断し、サービスの継続が不適当と判断される場合にはサーバを停止する。

より詳細には以下の構成も本発明に含まれる。

複数の業務サーバで構成される冗長化構成を有する分散系の業務システムにおける信頼性向上のための方法もしくは装置あるいはそのためのプログラムにおいて、前記業務システムと接続される管理装置が、前記複数のサーバそれぞれから稼働情報の入力を受付け、受付けられた前記稼働情報が所定の条件を満たすか否かにより前記複数のサーバ各々が異常状態かを判定し、判定の結果、異常状態と判定されるサーバが存在される場合には、当該サーバに対して停止指示を出力することにより、当該サーバを前記業務システムから切り離す。また、この信頼性向上の技術において、前記管理装置は、前記稼働情報として、前記複数のサーバのミドルウエアおよびオペレーティングシステムの少なくとも一方かが出力する異常メッセージを受付けた場合、異常状態であると判定することも本発明に含まれる。

また、前記管理装置は、前記稼働情報として前記複数のサーバのリソース情報を受付けることも本発明に含まれる。

さらに、前記異常メッセージには、それぞれレベルの異なる第1および第2の異常メッセージが含まれ、前記管理装置が、前記第１の異常メッセージを受付けた場合、即時に前記停止指示を出力することも含まれる。ここで、前記第２の異常メッセージを一定期間内に所定数以上受付けた場合、前記停止指示を出力することや前記管理装置が、前記第２の異常メッセージを前記一定期間内に前記所定数未満受付けた場合、当該第２の異常メッセージを出力するサーバに対する調査を指示する情報を出力することも本発明に含まれる

本発明によれば、サーバでの障害発生時の影響拡大の防止が可能となる。

以下、本発明の実施の形態を詳細に説明する。
図１は、複数台のサーバの冗長構成を有する分散系システムであるA業務システムの概要図である。連携元システム2からA業務システム1に対する取引電文4は、負荷分散装置3によりラウンドロビン等の振分け方式に従い同一構成を採る業務サーバ1a、1b、1cに振分けられる。その際、例えば一台の業務サーバ1aが障害により稼働不能となった場合には、負荷分散装置3が業務サーバ1aの障害を検知し、以降の電文の業務サーバ1aへの振り分けを停止し、残りの業務サーバ1bと1cへ振り分けることによりサービスを継続する。各サーバは、サーバの稼働状態を示す稼働情報を保有している。

図2は、図１で示したA業務システム1に対して、本発明における信頼性向上方式を適用したときのブロック図である。業務システム1は冗長化された業務サーバ1a,1b,1cから構成されているが、業務サーバ1a,1b,1cは同一構成であるため、ここではサーバ1aを例にとり説明する。業務サーバ1aは、サービス提供中のサーバの稼働情報10を保有している。稼働情報とは、ハードウェアやオペレーティングシステム、ミドルウェアが出力するエラーメッセージである異常メッセージ11や、CPUやメモリ、プロセスの状態といったリソース状態12を意味している。また、業務サーバ1aには、緊急時にサーバを強制的に停止するための強制停止機構13を有している。

稼働分析装置14においては、予めデータ管理機能部15として、レベル定義済みメッセージデータ16とリソース閾値データ17を保有する。レベル定義済みメッセージデータ16とは、サーバが出力するメッセージに対し、予めサービスに及ぼす危険度合いをレベル定義付けしたものである。本レベル付けは、メッセージの意味合いや過去に発生した障害実績から行うものであり、適当なタイミングで追加、更新などを実施する。リソース閾値データ17とは、サーバのリソース状態について、サービスに対する危険度合いを利用率の閾値として定義、あるいはリソースのそのものが正常状態か否かを判断するための情報を定義したものである。

業務サーバにて異常メッセージ11が出力した際には、稼働分析装置14に対し即時に通知する。また、リソース状態12は稼働分析装置14に対し一定期間毎（例えば10秒間隔）で通知する。稼働分析装置14では、業務サーバから通知された異常メッセージ11とリソース状態12をそれぞれレベル定義済みメッセージデータ16とリソース閾値データ17と、稼働分析装置14の異常判断機能部18において比較した上で取るべきアクションを決定し、運用管理システム19に通知する。運用管理システム19では、稼働分析装置14の異常判断機能部18からの通知内容に従い、業務サーバを強制停止機構13により強制停止、あるいは運用管理者20への通報を実施する。

図3は、稼働分析装置14のデータ管理機能部15のデータ構成を示す図である。データ管理機能部15は、サーバ稼働状態101とレベル定義済みメッセージデータ16とリソース閾値データ17を保持する。

サーバ稼働状態101は、業務システム毎の各サーバの稼働状態を一元管理している。状態には、「稼動中」と「停止中」の二つの状態がある。図3では、一例としてA業務システムの業務サーバA-a、A-b、A-cは稼動中であることを示している。仮に障害により業務サーバA-cが停止すると、当該サーバの状態は「停止中」に変化する。

レベル定義済みメッセージデータ16は、業務システム毎の業務サーバの出力するメッセージを予め記述し、レベル定義付けしたものである。レベルには、「致命的」と「要注意」と「その他」の三つのレベルがある。「致命的」とは、サービスに即座に影響のあるメッセージに対して設定するレベルであり、例えばサーバのI/Oタイムアウトを引き起こす恐れがあるメッセージは本レベルに該当する。「要注意」とは、即座にサービスに影響がある訳ではないものの、継続して出力するといずれサービスに影響が発生する可能性があるメッセージであり、例えば、メモリの1ビットエラーを表すメッセージは本レベルに該当する。「問題なし」とは、サービスに影響のないことが明らかなメッセージに対して設定するレベルであり、例えば各種ミドルウェアが出力するインフォメーションメッセージは本レベルに該当する。図3では、一例としてXXXXX-11111 Error、YYYYY-22222 Error、ZZZZZ-33333 Errorの3つのメッセージを設定し、それぞれのレベルを「致命的」、「致命的」、「要注意」と定義している。

リソース閾値データ17は、業務システム毎の業務サーバのリソースに関する閾値と経過時間を予め定義したものである。図3では、一例としてCPU利用率について閾値90％、経過時間60秒、メモリ利用率について閾値80％、経過時間60秒、プロセス状態について、予め起動しているべきプロセスが起動しているか否かを「正常」か「異常」の状態で示している。なお、プロセス状態は異常時に即座に通知するため経過時間を0秒としている。

図4は、稼働分析装置14の異常判断機能部18における異常メッセージ出力時の動作論理を示している。異常メッセージ11が出力されると判定を開始（ステップ1001）し、異常メッセージを出力したサーバが冗長化配置されたサーバのうち稼動中状態である唯一のサーバか否かをデータ機能管理部15のサーバ稼働状態101により判定する（ステップ1002）。ステップ1002にてYesの場合には、当該業務システムにて稼働している最後のサーバであることから、そのサーバに障害が発生した場合に業務が停止するため、早急に管理者に通報する（ステップ1003）。管理者用の端末に、調査を必要とする旨表示することで、管理者が調査を行うことが可能となる。ステップ1002にてNoの場合は、出力メッセージをレベル定義済みメッセージ16と照合し、そのメッセージが「致命的」であるか否かを判定する（ステップ1004）。ステップ1004にてYesの場合には、障害による影響拡大を防止するため、即座にサーバを強制停止する（ステップ1005）。ステップ1004にてNoの場合は、再度出力メッセージをレベル定義済みメッセージ16と照合し、そのメッセージが「要注意」であるか否かを判定する（ステップ1006）。ステップ1006にてYesの場合には、「要注意」メッセージがその後も継続して出力されている状態であるか否かを判定する（ステップ1007）。ステップ1007にてYesの場合には、今後の影響拡大を未然に防ぐため、サーバを強制停止する（ステップ1012）。ステップ1007にてNoの場合には、状況確認のため管理者への通報を実施する（ステップ1009）。ステップ1006にてNoの場合には、さらに出力メッセージをレベル定義済みメッセージ16と照合し、そのメッセージが「その他」であるか否かを判定する（ステップ1008）。ステップ1008にてYesの場合には、処理を継続しエラーメッセージをクリアする（ステップ1011）。ステップ1008にてNoの場合には、出力メッセージの内容の詳細を調査するため管理者に通報する（ステップ1010）。

図5は、稼働分析装置14の異常判断機能部18における異常リソース状態時の動作論理を示している。図2に示すように業務サーバ1ａのリソース状態12が一定の間隔で稼働分析装置14に通知され、通知される毎に判定が開始される（ステップ1101）。まず、業務サーバ1ａより通知されたリソース状態12が、稼働分析装置14のリソース閾値データ17を満足するか否かを判断する（ステップ1102）。ステップ1102でNoの場合には、特に問題はないため処理を継続する（ステップ1103）。ステップ1102でYesの場合には、リソースの閾値超過が、特性のサーバではなく全てのサーバにおいて発生しているか否かを判定する（ステップ1104）。これは、リソースの閾値超過が単一にサーバにおける異常、すなわち障害に起因するものなのか、それともシステム全体でリソースの状態が変化、すなわち業務特性に起因するものなのかを判断するものである。ステップ1104でYesの場合には、業務特性に起因するものと判断できるため管理者に通知し調査を実施する（ステップ1105）。ステップ1104でNoの場合には、特定サーバの障害に起因するのもであると判断できるため、ステップ1106に進む。ステップ1106においては、リソース閾値超過が発生したサーバが冗長化配置されたサーバのうち稼動中状態である唯一のサーバか否かをデータ機能管理部15のサーバ稼働状態101により判定する。ステップ1106にてYesの場合には、当該業務システムにて稼働している最後のサーバであることから、そのサーバに障害が発生した場合に業務が停止するため、早急に管理者に通知し調査を行う（ステップ1107）。ステップ1107にてNoの場合は、リソース閾値超過の状態が、リソース閾値データ17にて設定している経過時間以上に渡り継続しているか否かを判断する（ステップ1108）。ステップ1108にてNoの場合には、リソース状態が一定期間後に異常状態から回復したことを示しており、管理者に通知し調査を行うこととする（ステップ1109）。ステップ1108にてYesの場合には、今後の影響拡大を未然に防ぐため、サーバを強制停止する（ステップ1110）。

一例として、A業務システム１の業務サーバA-a、A-b、A-cが安定稼動中に、業務サーバA-aのみにおいてオペレーティングシステムにて異常メッセージ11としてYYYYY-22222 Errorのメッセージが出力されたときの動作を示す。YYYYY-22222 Errorは、過去I/Oタイムアウトを引き起こした障害が発生した際に出力されたメッセージであるとする。異常メッセージが出力されると同時に稼動分析装置14に対して即時に通知され、ステップ1001にて判定が開始されステップ1002に遷移する。ステップ1002にて、データ管理機能部15のサーバ稼働状態101のA業務システム稼働状態テーブル102を参照し、A業務システムに関連するサーバが稼動中状態であることがわかる。従って、ステップ1002ではNoと判定されステップ1004に遷移する。ステップ1004にて、データ管理機能部15のレベル定義済みメッセージデータ16のA業務システムレベル定義済みメッセージデータ103を検索し、メッセージYYYYY-22222 Errorがレベル「致命的」で登録されていることがわかる。従って、ステップ1004ではYesと判定されステップ1005に遷移する。ステップ1005にて、異常判断機能部18から運用管理システム19に通知し、運用管理システム19は業務サーバA-aの強制停止機構13に対し強制停止の指示を行い、業務サーバA-aは稼働を停止する。その後、業務サーバA-aの稼働停止を負荷分散装置3が検知し、以降業務サーバA-aへの取引電文の振り分けは行われない。なお、その際、データ管理機能部15のサーバ稼働状態101のA業務システム稼働状態テーブル102にて業務サーバA-aの状態は「停止中」に変化する。業務サーバA-aの停止により、従来ではそのまま業務サーバA-aに取引電文が到着した場合には、業務サーバA-aに到着した取引にI/Oタイムアウトが発生し、サービスに対して重大な影響が出ていた事態を回避できる。

システム概要図ブロック図データ機能管理部異常判断機能部の異常メッセージ出力時の動作フローチャート異常判断機能部の異常リソース状態時の動作フローチャート

符号の説明

1：A業務システム
1a,1b,1c：A業務システムを構成する業務サーバ
2：A業務システムへ連携する業務システム
3：負荷分散装置
4a,4b,4c：連携元システムからA業務システムへの取引電文
10：業務サーバA-aにおける稼働情報
11：業務サーバA-aにおける異常メッセージ
12：業務サーバA-aにおけるリソース状態
13：業務サーバA-aの強制停止機構
14：稼働分析装置
15：稼働分析装置におけるデータ機能管理部
16：稼働分析装置におけるレベル定義済みメッセージデータ
17：稼働分析装置におけるリソース閾値データ
18：稼働分析装置における異常判断機能部
19：運用管理システム
20：運用管理者
30：A業務システムから稼働分析装置への異常メッセージの通知
31：A業務システムから稼働分析装置へのリソース状態の通知
32：稼働分析装置から運用管理システムへの通知
33：運用管理システムからA業務システムの強制停止機構への通知
34：運用管理システムから運用管理者への通知
101：データ機能管理部のサーバ稼働状態
102：データ機能管理部のA業務システムに関するサーバ稼働状態
103：データ機能管理部のA業務システムに関するレベル定義済みメッセージデータ
104：データ機能管理部のA業務システムに関するリソース閾値データ
1001：異常メッセージ出力時の判定開始処理
1002：異常メッセージ出力時の分岐処理
1003：異常メッセージ出力時のアクション
1004：異常メッセージ出力時の分岐処理
1005：異常メッセージ出力時のアクション
1006：異常メッセージ出力時の分岐処理
1007：異常メッセージ出力時の分岐処理
1008：異常メッセージ出力時の分岐処理
1009：異常メッセージ出力時のアクション
1010：異常メッセージ出力時のアクション
1011：異常メッセージ出力時のアクション
1012：異常メッセージ出力時のアクション
1101：異常リソース状態時の判定開始処理
1102：異常リソース状態時の分岐処理
1103：異常リソース状態時のアクション
1104：異常リソース状態時の分岐処理
1105：異常リソース状態時のアクション
1106：異常リソース状態時の分岐処理
1107：異常リソース状態時のアクション
1108：異常リソース状態時の分岐処理
1109：異常リソース状態時のアクション
1110：異常リソース状態時のアクション

Claims

複数の業務サーバで構成される冗長化構成を有する分散系の業務システムにおける信頼性向上方法において、
前記業務システムと接続される管理装置が、
前記複数のサーバそれぞれから稼働情報の入力を受付け、
受付けられた前記稼働情報が所定の条件を満たすか否かにより前記複数のサーバ各々が異常状態かを判定し、
判定の結果、異常状態と判定されるサーバが存在される場合には、当該サーバに対して停止指示を出力することにより、当該サーバを前記業務システムから切り離すことを実現することを特徴とする信頼性向上方法。
請求項１に記載の信頼性向上方法において、
前記管理装置は、前記稼働情報として、前記複数のサーバのミドルウエアおよびオペレーティングシステムの少なくとも一方かが出力する異常メッセージを受付けた場合、異常状態であると判定することを特徴とする信頼性向上方法。
請求項１に記載の信頼性向上方法において、
前記管理装置は、前記稼働情報として前記複数のサーバのリソース情報を受付けることを特徴とする信頼性向上方法。
請求項２に記載の信頼性向上方法において、
前記異常メッセージには、それぞれレベルの異なる第1および第2の異常メッセージが含まれ、
前記管理装置が、前記第１の異常メッセージを受付けた場合、即時に前記停止指示を出力し、前記第２の異常メッセージを一定期間内に所定数以上受付けた場合、前記停止指示を出力することを特徴とする信頼性向上方法。
請求項４に記載の信頼性向上方法において、
前記管理装置が、前記第２の異常メッセージを前記一定期間内に前記所定数未満受付けた場合、当該第２の異常メッセージを出力するサーバに対する調査を指示する情報を出力することを特徴とする信頼性向上方法。