特許 6209138 運用管理サーバ、運用プログラム及びサーバ運用方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6209138

(24)【登録日】2017年9月15日

(45)【発行日】2017年10月4日

(54)【発明の名称】運用管理サーバ、運用プログラム及びサーバ運用方法

(51)【国際特許分類】

   G06F 11/07 20060101AFI20170925BHJP

【ＦＩ】

   G06F11/07 154

   G06F11/07 166

   G06F11/07 140A

【請求項の数】3

【全頁数】10

(21)【出願番号】特願2014-151205(P2014-151205)

(22)【出願日】2014年7月24日

(65)【公開番号】特開2016-24790(P2016-24790A)

(43)【公開日】2016年2月8日

【審査請求日】2016年8月2日

(73)【特許権者】

【識別番号】000237639

【氏名又は名称】富士通フロンテック株式会社

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】岡安 弘之

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２０１２−０８８７９７（ＪＰ，Ａ）

【文献】 特開２００７−３２３１９３（ＪＰ，Ａ）

【文献】 特開２０１１−１９２０９７（ＪＰ，Ａ）

【文献】 国際公開第２０１１／１２５１３８（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ１１／０７

Ｇ０６Ｆ１１／３０−１１／３４

(57)【特許請求の範囲】

【請求項1】

互いに協調して分散処理を行う複数の管理対象サーバの各々の稼働状態を判断し、前記複数の管理対象サーバを、正常サーバまたは異常サーバの何れかに分別する稼働状態判断部と、
前記複数の管理対象サーバの何れかのリソース使用率が閾値以上になるときに、アラーム出力部にアラームを出力させるアラーム判定部と、
前記正常サーバの台数が減少するほど、または、前記異常サーバの台数が増加するほど、前記閾値を増加させる閾値制御部と、
を具備する運用管理サーバ。

【請求項2】

互いに協調して分散処理を行う複数の管理対象サーバの各々の稼働状態を判断し、前記複数の管理対象サーバを、正常サーバまたは異常サーバの何れかに分別し、
前記正常サーバの台数が減少するほど、または、前記異常サーバの台数が増加するほど、閾値を増加させ、
前記複数の管理対象サーバの何れかのリソース使用率が前記閾値以上になるときに、アラーム出力部にアラームを出力させる
処理を運用管理サーバに実行させる運用プログラム。

【請求項3】

運用管理サーバが、互いに協調して分散処理を行う複数の管理対象サーバの各々の稼働状態を判断し、前記複数の管理対象サーバを、正常サーバまたは異常サーバの何れかに分別し、
前記運用管理サーバが、前記正常サーバの台数が減少するほど、または、前記異常サーバの台数が増加するほど、閾値を増加させ、
前記運用管理サーバが、前記複数の管理対象サーバの何れかのリソース使用率が前記閾値以上になるときにアラームを出力する、
サーバ運用方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、運用管理サーバ、運用プログラム及びサーバ運用方法に関する。

【背景技術】

【0002】

一のサーバが他のサーバの運用を管理する運用管理システムがある。以下では、他のサーバの運用を管理するサーバを「運用管理サーバ」と呼び、運用管理サーバの管理対象となるサーバを「管理対象サーバ」と呼ぶことがある。管理対象サーバは端末装置と接続され、端末装置からの要求に応じて各種の処理を行う。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００２−２１５２３０号公報

【特許文献2】特開２００３−２６３３４２号公報

【特許文献3】特開２００４−３０２９３７号公報

【特許文献4】特開２００５−３１６８０８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

運用管理サーバとして、管理対象サーバのリソース使用率を監視し、管理対象サーバのリソース使用率が閾値以上となるときにアラームを発することで、端末装置から管理対象サーバへ要求された処理の量が大きくなっていることを運用作業者に知らせるものがある。監視されるリソース使用率としては、例えば、ＣＰＵ（Central Processing Unit）使用率、メモリ使用率等がある。以下では、アラーム発生の基準となる閾値を「アラーム閾値」と呼ぶことがある。

【0005】

複数のサーバが互いに協調して分散処理を行う分散処理システムでは、複数のサーバが運用管理の対象となる。分散処理を行う管理対象サーバの数が増加するほど、管理対象サーバ１台あたりの処理負荷は減少する。よって、分散処理システムでは、端末装置から要求された処理の量、すなわち、分散処理システム全体における処理負荷が大きくなっていることを知らせるためのアラーム閾値は、分散処理を行わない場合に比べて、小さい値に設定される。また、分散処理システムでのアラーム閾値は、複数の管理対象サーバのすべてが正常に稼働している状態にあることを前提にして予め設定される。

【0006】

ここで、分散処理を行う管理対象サーバの何れかに障害が発生して縮退運用となる場合は、複数の管理対象サーバのすべてが正常に稼働している場合に比べ、管理対象サーバ１台あたりの処理負荷が増加する。よって、アラーム閾値が、複数の管理対象サーバのすべてが正常に稼働している状態にあることを前提に設定された固定値であると、分散処理システム全体における処理負荷が縮退運用前後で変わらないにもかかわらず、縮退運用時にはアラームが頻繁に発せられてしまうことがある。

【0007】

このように、分散処理システムにおいてアラーム閾値が固定値であると、縮退運用前後でアラームの発生頻度が変わってしまうことがある。しかし、分散処理システム全体における処理負荷が縮退運用前後で変わっていないにもかかわらず、アラームの発生頻度が縮退運用前後で変わってしまうことは好ましくない。

【0008】

開示の技術は、上記に鑑みてなされたものであって、分散処理システムにおいて、アラーム発生の基準となる閾値を適正に制御することを目的とする。

【課題を解決するための手段】

【0009】

開示の態様では、運用管理サーバは、稼働状態判断部と、アラーム判定部と、閾値制御部とを有する。前記稼働状態判断部は、互いに協調して分散処理を行う複数の管理対象サーバの各々の稼働状態を判断し、前記複数の管理対象サーバを、正常サーバまたは異常サーバの何れかに分別する。前記アラーム判定部は、前記複数の管理対象サーバの何れかのリソース使用率が閾値以上になるときに、アラーム出力部にアラームを出力させる。前記閾値制御部は、前記正常サーバの台数が減少するほど、または、前記異常サーバの台数が増加するほど、前記閾値を増加させる。

【発明の効果】

【0010】

開示の態様によれば、分散処理システムにおいて、アラーム発生の基準となる閾値を適正に制御することができる。

【図面の簡単な説明】

【0011】

【図1】図１は、実施例１の運用管理システムの構成例を示す図である。

【図2】図２は、実施例１の運用管理サーバの構成例を示す機能ブロック図である。

【図3】図３は、実施例１の運用管理サーバの動作の説明に供する図である。

【図4】図４は、実施例１の運用管理サーバの動作の説明に供する図である。

【図5】図５は、実施例１の運用管理サーバの処理の説明に供するフローチャートである。

【図6】図６は、実施例１の運用管理サーバのハードウェア構成例を示す図である。

【発明を実施するための形態】

【0012】

以下に、本願の開示する運用管理サーバ、運用プログラム及びサーバ運用方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本願の開示する運用管理サーバ、運用プログラム及びサーバ運用方法が限定されるものではない。

【0013】

また、以下の実施例では、管理対象サーバに処理要求を行う端末装置として、銀行オンラインシステムにおける「ＡＴＭ（Automated Teller Machine）端末」を一例に挙げて説明する。しかし、開示の技術が適用可能な端末装置は、ＡＴＭ端末に限定されない。開示の技術は、ＡＴＭ端末以外の端末装置が運用管理システムに処理要求を行う場合にも適用可能である。

【0014】

［実施例１］
＜運用管理システムの構成＞
図１は、実施例１の運用管理システムの構成例を示す図である。図１に示す運用管理システム１は、運用管理サーバ１０と、ＡＴＭ端末２０−１〜２０−３と、管理対象サーバ４０−１〜４０−４とを有する。管理対象サーバ４０−１〜４０−４と、ＡＴＭ端末２０−１〜２０−３とは、ネットワーク３０を介して接続される。また、管理対象サーバ４０−１〜４０−４は、ＡＴＭ端末２０−１〜２０−３からの処理要求に対し、互いに協調して分散処理を行うものである。つまり、管理対象サーバ４０−１〜４０−４と、ネットワーク３０と、ＡＴＭ端末２０−１〜２０−３とは、分散処理システムである銀行オンラインシステムを形成する。

【0015】

以下では、管理対象サーバ４０−１〜４０−４を区別しない場合には、管理対象サーバ４０と総称することがある。また、ＡＴＭ端末２０−１〜２０−３を区別しない場合には、ＡＴＭ端末２０と総称することがある。また、図１では、４台の管理対象サーバ４０を一例として挙げているが、運用管理サーバ１０に接続可能な管理対象サーバ４０の台数は４台に限定されない。また、図１では、３台のＡＴＭ端末２０を一例として挙げているが、管理対象サーバ４０に接続可能なＡＴＭ端末２０の台数は３台に限定されない。

【0016】

＜運用管理サーバの構成＞
図２は、実施例１の運用管理サーバの構成例を示す機能ブロック図である。図２に示す運用管理サーバ１０は、通信部１１と、稼働状態判断部１２と、閾値制御部１３と、閾値記憶部１４と、アラーム判定部１５と、アラーム出力部１６とを有する。

【0017】

通信部１１は、管理対象サーバ４０と互いに通信する。通信部１１は、応答要求に対する応答を管理対象サーバ４０から受信して稼働状態判断部１２へ出力する。また、通信部１１は、エラーメッセージを管理対象サーバ４０から受信して稼働状態判断部１２へ出力する。また、通信部１１は、管理対象サーバ４０のリソース使用率を管理対象サーバ４０から受信して、稼働状態判断部１２及びアラーム判定部１５へ出力する。管理対象サーバ４０−１〜４０−４の各々は、自機におけるリソース使用率を運用管理サーバ１０へ送信する。

【0018】

稼働状態判断部１２は、通信部１１から入力される応答、エラーメッセージ、または、リソース使用率に基づいて、管理対象サーバ４０−１〜４０−４の各々の稼働状態を判断し、管理対象サーバ４０−１〜４０−４を、「正常サーバ」または「異常サーバ」の何れかに分別する。「正常サーバ」とは、障害が発生しておらず、正常に稼働しているサーバである。また、「異常サーバ」とは、稼働中に障害が発生したサーバ、または、稼働していないサーバである。

【0019】

例えば、稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４の各々へ応答要求を送信することにより稼働状態を判断する。すなわち、稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４のうち、応答要求に対して応答を返信したサーバを正常サーバに分別し、応答要求に対して応答がなかったサーバを異常サーバに分別する。

【0020】

また例えば、稼働状態判断部１２は、エラーメッセージの有無に基づいて稼働状態を判断する。すなわち、稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４のうち、エラーメッセージを運用管理サーバ１０へ送信したサーバを異常サーバに分別する。例えば、エラーメッセージは、管理対象サーバ４０で実行される業務アプリケーションの起動が失敗したとき、または、管理対象サーバ４０で実行される業務アプリケーションが異常終了したとき等に、管理対象サーバ４０から運用管理サーバ１０へ送信される。

【0021】

また例えば、稼働状態判断部１２は、管理対象サーバ４０のリソース使用率に基づいて稼働状態を判断する。すなわち、稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４のうち、リソース使用率が「エラー閾値」以上であるサーバを異常サーバに分別し、リソース使用率が「エラー閾値」未満であるサーバを正常サーバに分別する。「エラー閾値」は「アラーム閾値」より大きい値を持ち、例えば、管理対象サーバ４０において処理エラーが頻発するようになるリソース使用率を基準にして「エラー閾値」が設定される。「エラー閾値」は、予め、稼働状態判断部１２に設定される。

【0022】

稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４を正常サーバまたは異常サーバの何れかに分別後、正常サーバの台数、及び、異常サーバの台数をカウントする。そして、稼働状態判断部１２は、カウントした正常サーバの台数及び異常サーバの台数を閾値制御部１３へ出力する。

【0023】

閾値制御部１３は、閾値記憶部１４に記憶されているアラーム閾値を、異常サーバの台数または正常サーバの台数に基づいて制御する。

【0024】

すなわち、閾値制御部１３は、異常サーバの台数が増加するほどアラーム閾値を増加させる。異常サーバの台数に応じたアラーム閾値の制御は、例えば以下の式（１）に従って行われる。
アラーム閾値＝初期値＋（異常サーバの台数×α） …（１）

【0025】

または、閾値制御部１３は、正常サーバの台数が減少するほどアラーム閾値を増加させる。正常サーバの台数に応じたアラーム閾値の制御は、例えば以下の式（２）に従って行われる。
アラーム閾値
＝初期値＋（（管理対象サーバ４０の総数−正常サーバの台数）×α） …（２）

【0026】

式（１），（２）において、「初期値」は、管理対象サーバ４０−１〜４０−４のすべてが正常サーバであることを前提にした所定値であり、閾値記憶部１４に予め設定されている。また、「α」は所定の係数である。また、「初期値」、「α」及び「管理対象サーバ４０の総数」は、閾値制御部１３に既知である。

【0027】

なお、管理対象サーバ４０−１〜４０−４は正常サーバまたは異常サーバの何れかに分別されるため、式（２）における「管理対象サーバ４０の総数」は、正常サーバの台数と異常サーバの台数との合計数に等しい。よって、式（２）における「管理対象サーバ４０の総数−正常サーバの台数」は、異常サーバの台数に等しい。つまり、異常サーバの台数が増加することは、正常サーバの台数が減少することと等価である。

【0028】

アラーム判定部１５は、通信部１１から入力されるリソース使用率と、閾値記憶部１４に記憶されているアラーム閾値とを比較し、比較結果に基づいて、アラームを発生させるか否かを判定する。すなわち、アラーム判定部１５は、管理対象サーバ４０−１〜４０−４の何れかのリソース使用率がアラーム閾値以上であるときに、アラームを発生させると判定する。一方で、アラーム判定部１５は、管理対象サーバ４０−１〜４０−４のすべてのリソース使用率がアラーム閾値未満であるときに、アラームを発生させないと判定する。アラーム判定部１５は、アラームを発生させると判定したときは、アラーム出力部１６にアラームを出力させる。一方で、アラーム判定部１５は、アラームを発生させないと判定したときは、アラーム出力部１６にアラームを出力させない。

【0029】

アラーム出力部１６は、アラーム判定部１５からの上記制御に従って、アラームを出力する。よって、アラーム出力部１６は、管理対象サーバ４０−１〜４０−４の何れかのリソース使用率がアラーム閾値以上であるときに、アラームを出力する。一方で、アラーム出力部１６は、管理対象サーバ４０−１〜４０−４のすべてのリソース使用率がアラーム閾値未満であるときに、アラームを出力しない。アラームは、音によるアラームでもよく、また、表示によるアラームでもよい。アラームが音によるものであるときは、例えば、アラーム出力部１６は、運用管理サーバ１０が有するスピーカにより実現される。また、アラームが表示によるものであるときは、例えば、アラーム出力部１６は、運用管理サーバ１０に接続されたディスプレイにより実現される。よって、表示によるアラームだけでよいときは、運用管理サーバ１０は、アラーム出力部１６を備えなくてもよい。

【0030】

＜運用管理サーバの動作＞
図３及び図４は、実施例１の運用管理サーバの動作の説明に供する図である。以下では、監視対象となるリソース使用率として、ＣＰＵ使用率と、メモリ使用率とを採用した場合について説明する。

【0031】

図３には、アラーム閾値及びエラー閾値の初期値を示す。一方で、図４には、正常サーバの台数が当初より減少したとき（つまり、異常サーバの台数が当初より増加したとき）のアラーム閾値及びエラー閾値を示す。

【0032】

すなわち、ＣＰＵ使用率のアラーム閾値の初期値は「８０％」であるのに対し、正常サーバの台数が当初より減少したときのアラーム閾値は「９５％」に増加する。また、メモリ使用率のアラーム閾値の初期値は「７０％」であるのに対し、正常サーバの台数が当初より減少したときのアラーム閾値は「８５％」に増加する。よって、当初は、管理対象サーバ４０−１〜４０−４の何れかのＣＰＵ使用率が８０％以上になったとき、または、管理対象サーバ４０−１〜４０−４の何れかのメモリ使用率が７０％以上になったときに、アラームが出力される。一方で、正常サーバの台数が当初より減少したときは、管理対象サーバ４０−１〜４０−４の何れかのＣＰＵ使用率が９５％以上になるまで、または、管理対象サーバ４０−１〜４０−４の何れかのメモリ使用率が８５％以上になるまで、アラームは出力されない。

【0033】

また、ＣＰＵ使用率のエラー閾値は、正常サーバの台数の変化にかかわらず、「９８％」で一定である。また、メモリ使用率のエラー閾値は、正常サーバの台数の変化にかかわらず、「９０％」で一定である。

【0034】

正常サーバの台数に応じたアラーム閾値の増減の制御は、上記のように、閾値制御部１３によって行われる。また、エラー閾値は、上記のように、予め、稼働状態判断部１２に設定されている。

【0035】

＜運用管理サーバの処理＞
図５は、実施例１の運用管理サーバの処理の説明に供するフローチャートである。図５に示すフローチャートは、一定時間毎に開始される。

【0036】

稼働状態判断部１２は、管理対象サーバ４０−１〜４０−４の稼働状態を判断し、管理対象サーバ４０−１〜４０−４を正常サーバと異常サーバとに分別する（ステップＳ２１）。

【0037】

次いで、閾値制御部１３は、稼働状態の前回の判断時と、今回の判断時とで、正常サーバまたは異常サーバの台数に変化があるか否かを判断する（ステップＳ２２）。

【0038】

正常サーバまたは異常サーバの台数に変化がある場合（ステップＳ２２：Ｙｅｓ）、閾値制御部１３は、閾値記憶部１４に記憶されているアラーム閾値を、正常サーバの台数または異常サーバの台数に基づいて変更する（ステップＳ２３）。アラーム閾値の変更後、処理はステップＳ２４へ進む。

【0039】

一方で、正常サーバまたは異常サーバの台数に変化がない場合（ステップＳ２２：Ｎｏ）、閾値制御部１３は、閾値記憶部１４に記憶されているアラーム閾値を変更せずに、処理はステップＳ２４へ進む。

【0040】

ステップＳ２４では、アラーム判定部１５が、閾値記憶部１４を参照し、管理対象サーバ４０−１〜４０−４の何れかのリソース使用率がアラーム閾値以上か否かを判定する（ステップＳ２４）。

【0041】

管理対象サーバ４０−１〜４０−４の何れかのリソース使用率がアラーム閾値以上であるときは（ステップＳ２４：Ｙｅｓ）、アラーム出力部１６は、アラームを出力し（ステップＳ２５）、処理は終了する。

【0042】

一方で、管理対象サーバ４０−１〜４０−４のすべてのリソース使用率がアラーム閾値未満であるときは（ステップＳ２４：Ｎｏ）、アラーム出力部１６がアラームを出力せずに、処理は終了する。

【0043】

以上のように、実施例１によれば、運用管理サーバ１０は、稼働状態判断部１２と、アラーム判定部１５と、閾値制御部１３とを有する。稼働状態判断部１２は、互いに協調して分散処理を行う管理対象サーバ４０−１〜４０−４の各々の稼働状態を判断し、管理対象サーバ４０−１〜４０−４を、正常サーバまたは異常サーバの何れかに分別する。アラーム判定部１５は、管理対象サーバ４０−１〜４０−４の何れかのリソース使用率がアラーム閾値以上になるときに、アラーム出力部に１６アラームを出力させる。閾値制御部１３は、正常サーバの台数が減少するほど、または、異常サーバの台数が増加するほど、アラーム閾値を増加させる。

【0044】

こうすることで、正常サーバの台数が減少する（つまり、異常サーバの台数が増加する）縮退運用時にはアラーム閾値が増加するため、分散処理システム全体における処理負荷が縮退運用前後で変わらないにもかかわらずアラーム発生頻度が縮退運用前後で変わることを防止できる。つまり、分散処理システムにおいて、アラーム閾値を適正に制御することができる。また、縮退運用時には、正常サーバの台数の減少（つまり、異常サーバの台数の増加）に応じた適正なアラーム閾値に自動的に制御されるため、縮退運用時のアラーム閾値の設定に関して、運用作業者の作業負担を軽減できる。

【0045】

＜運用管理サーバのハードウェア構成＞
運用管理サーバ１０は、例えば、次のようなハードウェア構成により実現することができる。図６は、実施例１の運用管理サーバのハードウェア構成例を示す図である。図６に示すように、運用管理サーバ１０は、ハードウェアの構成要素として、プロセッサ１０ａと、メモリ１０ｂと、通信インタフェースモジュール１０ｃとを有する。プロセッサ１０ａの一例として、ＣＰＵ（Central Processing Unit），ＤＳＰ（Digital Signal Processor），ＦＰＧＡ（Field Programmable Gate Array）等が挙げられる。また、運用管理サーバ１０は、プロセッサ１０ａと周辺回路とを含むＬＳＩ（Large Scale Integrated circuit）を有してもよい。メモリ１０ｂの一例として、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory），ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。通信部１１は、通信インタフェースモジュール１０ｃによって実現される。稼働状態判断部１２と、閾値制御部１３と、アラーム判定部１５とは、プロセッサ１０ａによって実現される。閾値記憶部１４は、メモリ１０ｂによって実現される。アラーム出力部１６は、上記のように、スピーカ（図示せず）またはディスプレイ（図示せず）によって実現される。

【0046】

また、運用管理サーバ１０での上記説明における各処理は、各処理に対応するプログラムを運用管理サーバ１０に実行させることによって実現してもよい。例えば、上記説明における各処理に対応するプログラムがメモリ１０ｂまたはＨＤＤ（Hard Disk Drive）等の記憶部に記憶され、プログラムがプロセッサ１０ａによって記憶部から読み出されて実行されてもよい。

【0047】

なお、上記説明では、監視対象となるリソース使用率の一例として、ＣＰＵ使用率と、メモリ使用率とを挙げた。しかし、監視対象となるリソース使用率は、ＣＰＵ使用率及びメモリ使用率に限定されない。例えば、監視対象となるリソース使用率として、ディスク使用率、Ｉ／Ｏモジュール使用率等を採用してもよい。

【符号の説明】

【0048】

１ 運用管理システム
１０ 運用管理サーバ
２０−１〜２０−３ ＡＴＭ端末
３０ ネットワーク
４０−１〜４０−４ 管理対象サーバ
１１ 通信部
１２ 稼働状態判断部
１３ 閾値制御部
１４ 閾値記憶部
１５ アラーム判定部
１６ アラーム出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】