JP3826602B2 - システム運用管理装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はコンピュータシステムの運用に際し、多重ジョブ稼働により使用されるシステム資源を安定的に使用、維持させるためのシステム運用評価技術に関する。
【０００２】
【従来の技術】
オンライン／バッチ処理を問わず多数のジョブを多重で稼働させるようジョブ・スケジューリングされ、これが実行された時の各種システム資源（ハード、ソフト）の使用状況は、当然のことながら処理データ量やジョブ間の資源の競合などにより時々刻々変動する。
【０００３】
これ等ジョブ稼働によるシステム資源の使用状況についての評価技術には、各資源の使用状況をシステムの運用中に監視しており、予め与えられた所定の使用率に達した時メッセージ通知し直ちにアクションに繋げたり、自動判断可能なものはシステム内で然るべき措置を自動的に採るなど、資源使用状況の評価をシステムの運用中にリアルタイムで行うものと、本発明の様に各種システム資源の使用状況に関するデータを稼働ログ（ロギング）として一旦ファイルに採取し、その後これ等情報をもとに必要に応じて、或いは定期的にシステム全体の時系列的な資源使用状況からバッチ的に評価し、運用スケジュールや資源配分の安定化・効率化を図り、システム運用の最適化を追求するものとが存在する。
【０００４】
バッチ的に評価を行う後者の場合、従来一旦ファイルに採取されたシステム資源の稼働ログデータ、即ちジョブ稼働ログ（ジョブ・スケジューラにより管理されるジョブ名／稼働開始時刻／稼働終了時刻）、磁気ディスク稼働ログ（論理ディスク名／保有領域バイト／使用領域バイト／稼働率）、磁気ディスク内ファイル稼働ログ（ファイル名／ブロック長／レコード長／レコード数／使用領域バイト／稼働率）、磁気ディスク内ＤＢ稼働ログ（ＤＢ名／定義領域バイト／使用領域バイト／稼働率）、メモリの稼働ログ（スワップ回数）、ＣＰＵの稼働ログ（稼働率）、オンラインジョブの稼働ログ（ジョブ名／使用ユーザ数／レスポンスタイム）などの詳細な稼働状況を示すシステム資源別の実績データを時系列に出力し、システムの運用・維持を行う専門家がこれ等多量の各稼働ログ情報を時系列に突き合わせてシステムの性能評価を行い、性能低下の要因と考えられるシステム上のボトルネックを思考錯誤で抽出する。
【０００５】
その後この抽出された問題に対する解決策を追求するため、これ等抽出された稼働ログ情報に、ジョブが使用するソフト資源（ファイルなど）やシステムを構成するソフト資源（ＤＢ、ジョブなど）の定義体（ソース）情報を対応、突き合わせ問題ジョブに関係する定義体を特定し、これに対処するという具合に、極めて多岐にわたる多種・多量のデータを時系列的に突き合わせ、性能分析・診断することはシステム運用のエキスパートにとっても極めて困難な作業であり、長時間を要すものであった。
【０００６】
尚、ここでソフト資源の定義体情報とは、ジョブ・スケジュールソース、ジョブソース、プログラムソース、データベース（ＤＢ）ソース（ＤＢの定義体）、画面／帳票定義体などを指しており、システムの開発者や運用者が作成したり修正したりするものである。
【０００７】
【発明が解決しようとする課題】
この様に従来のシステム性能評価に於いては、資源別に管理された運用時に採取される各種稼働ログ情報（動的情報）と、各種ソフト資源の定義体情報（静的情報）が、システム運用のエキスパートの手で時系列データとして整理、統合され、これをもとに問題の抽出から解決までの作業が行われており、システム性能評価の可能な熟練者が必須である上、性能低下の要因抽出から解決策の究明、そしてその具体的な修正・対処に至る作業プロセスに長時間を要し、個人の経験・ノウハウに頼った非効率的な作業であるという問題があった。
【０００８】
本発明はこのような点にかんがみて、稼働ログ情報からバッチ的にシステム運用評価を行うシステム運用管理装置に於いて、これにソフト資源の定義体情報を同一管理下に置き、運用管理者とのインタラクティブな会話を通じてこれ等情報を時系列データとして整理、統合して運用管理者へ提供し、システムの性能評価を可能とする手段を提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記の課題は下記の如くに構成されたシステム運用管理装置によって解決される。即ち図１は、本発明の原理図であり、
コンピュータシステムの運用評価を行うシステム運用管理装置に於いて、
システムの稼働ログ情報とシステムを構成するソフト資源の定義体情報を記憶する評価情報記憶手段１０と、運用管理者が前記システム運用管理装置に指示を与えるリクエスト手段１１と、前記リクエスト手段からの指示内容にもとづき前記稼働ログ情報を検索し、該情報を時系列に編集する時系列編集手段１２と、前記時系列編集手段により編集され出力された情報にもとづき特定されたシステム性能の低下要因に関係する前記定義体情報を検索し、編集する定義体編集手段１３と、編集された情報を端末画面へ出力する画面出力手段１４とを備えることにより、運用管理者の思考に沿ったインタラクティブな会話を通じて運用評価に必要な情報を時系列に整理、統合して提供し、運用管理の熟練者でなくとも短時間にシステムの性能評価を可能とする。
【００１０】
【発明の実施の形態】
本発明は前記の通り、コンピュータシステムに於ける過去の稼働実績データ（ジョブ稼働ログ、磁気ディスク使用ログ、ファイル使用ログなど）を運用管理者（操作者）のリクエストに応じて各種の情報を提供し、これ等情報をもとに運用管理者は当該コンピュータシステムの運用上の問題点（要因：資源の領域的要因と負荷的要因とがある）を探し出し、この問題の解決策を追求するに当たり、これ等資源別の稼働実績データを運用管理者の要求に応じて時系列的に整理・統合して提供し、これに更にシステム又はジョブなどの定義体情報を関係付けた情報を提供することにより問題を特定し、その結果としてシステム又はジョブなどの定義体情報を修正変更、又はジョブの運用スケジュールを変更するなどして、システム資源（磁気ディスクなどのハードウエア資源、ジョブやファイルなどのソフトウエア資源）の使用効率化を図ることを主目的とするものである。これは換言すれば、システム資源の稼働ログデータをもとにシステム資源の動作を各種情報をもって時系列に再現させるシステムであり、稼働ログデータ（情報）と定義体情報を記憶する磁気ディスクなどの記憶装置と、運用管理者のリクエスト入力操作及びそのリクエストに対する応答出力を行うパソコンなどのディスプレイ端末と、必要に応じて検索結果などを出力するプリンタ装置とから構成される。
【００１１】
図２は本装置と運用管理者の間でインタラクティブな会話を通じて段階的に作業を進めて行く動作を概念的に表現したもので、四角で表した「Ａ」「Ｂ」などがマウスクリックなどのリクエスト手段の対象となる機能選択子であり、矢印はその機能選択子が選択された場合の行き先を表している。
【００１２】
図２の例では、ディスプレイなどの初期画面で「Ａ」が選択されると、その先に「Ｂ」「Ｃ」「Ｄ」の３通りの機能選択が存在し、ここで例えば「Ｄ」が選択された場合、その先には更に「Ｅ」を含む３通りの機能選択が存在する。
【００１３】
ここで例えば「Ｅ」が選択されると、初めてシステムの稼働ログ情報とシステムを構成するソフト資源の定義体情報を記憶する評価情報記憶手段から「Ｅ」で定義付けられた関係情報が時系列編集手段又は定義体編集手段により検索され、編集されて、画面出力手段を通じディスプレイなどの画面に出力される。
【００１４】
この出力された目的のデータ群の中から１つをリクエストすると、「Ｆ」機能選択に移行し、「Ｆ」で定義付けられた関係情報が前記同様に画面出力され、そのデータをもとに更にリクエストされると、「Ｇ」機能選択に移行し、「Ｇ」で定義付けられた関係情報が画面出力されると言う具合に、一連の操作の流れが不定形で運用管理者の思考に沿って順次作業が進められ、最後に目的のデータを入手すると言うオブジェクト指向に構成されたシステム運用管理装置である。尚、機能選択の途中で前の処理に戻ることは当然のことながら可能である。
【００１５】
本発明のシステム運用管理装置では、前述の通り従来資源別に管理されていた各種稼働ログ情報（動的情報）と、各種ソフト資源の定義体情報（静的情報）を同一管理下に置き、前記の作業手順に準じて運用管理者とのインタラクティブな会話を通じて運用管理者のリクエストに応じた情報を時系列データとして整理、統合して運用管理者へ提供し、システムの性能評価を行うことを特徴としているが、次にこれ等を具体例で説明する。
【００１６】
図３は本システム運用管理装置の初期画面例であり、ここでは主に調査をどの観点からエントリするかを選択するもので、本例では磁気ディスク（ボリューム）資源の容量的使用負荷の観点から調査を開始し、容量面で恒常的に負荷が高いボリューム、或いは容量的負荷が時間的に所定値より大きく変動する（不安定）ボリューム中のファイルを再配置し、他ボリュームとの容量的負荷バランスを改善することを目的とするため、初期画面では先ず「磁気ディスク資源管理」を選択する。
【００１７】
図４は初期画面からのエントリに始まる当調査の実施手順をフローチャート化したものであり、ステップ４０はこれを意味している。
【００１８】
次に例えば過去１週間（指定による）に於ける各ボリュームの最大容量に対する最低の空容量と空比率をボリューム一覧として表示し、その中で問題と思われるボリューム（これをボリュームＡとする）をクリック選択すると、そのボリュームＡの使用状況が図５に示す様に磁気ディスク稼働ログ情報から抽出され時系列にグラフ化されて表示される（ステップ４１）。この時のボリューム一覧に所定の条件（ボリュームの最低空容量、及び空比率に対する条件など）を与え、条件を満足するもののみを表示する様にしても良い。
【００１９】
この例は容量的負荷が所定値（最低値が最大値の１／４以下など）より大きく変動する、所謂不安定なボリュームの例であり、１９９８／１２／２７に最低の空容量５８０５ＴＲＫ（Track)を示している（ステップ４２の下方展開）。
【００２０】
次にこのグラフ上で容量の逼迫した最低の空容量を示すバーをクリック選択して時間帯別の詳細な使用状況をグラフ表示し、最低の空容量を示した時間帯を含む或る時間帯を指定して、同じく最低の空容量を示すバーをクリック選択すると、その時間帯でボリュームＡ上に存在したファイルを使用容量と共に磁気ディスク稼働ログ情報から抽出（ステップ４３）し、またボリュームＡ上に領域を確保して稼働していた稼働ジョブをジョブ稼働ログ情報（ジョブ名、開始時刻、終了時刻から成り、当ジョブで使用するファイルはジョブソース情報から取得）から抽出（ステップ４４）して、これ等を画面上に一覧表示する。この時これ等稼働ジョブが、どのファイルを使用するかジョブソース情報から抽出（ステップ４５）される。
【００２１】
続いて画面に一覧表示されたファイル（ステップ４３で抽出）の中から問題視されるファイル名がクリック選択されると、当ファイルを使用するジョブの一覧が表示（ステップ４６）され、ボリュームＡの容量逼迫原因と考えられるジョブとファイルが特定（ステップ４７）される。
【００２２】
この特定されたファイル名から当ファイルを使用する全箇所をジョブソース情報から抽出（ステップ４８）し、その影響範囲を特定（ステップ４９）した後、ステップ５０でその箇所のジョブソースを修正して作業を終了する。
【００２３】
また、もう一方の容量面で恒常的に負荷が高いボリューム中のファイルを再配置し、他ボリュームとの容量的負荷バランスを改善する場合には、ステップ４２の判断に於いて右方展開し、ボリュームＡ内のファイルを磁気ディスク稼働ログ情報から全て洗い出し表示（ステップ５１）し、洗い出されたファイルの必要性がジョブソースで定義されているか否かにより調査（ステップ５２）され、その結果（ステップ５３）、定義されていないファイルは不要なファイルと見なし消去（ステップ５４）され、必要なファイルについてはボリューム内ファイルを見直し格納ボリュームの再配置（ステップ５５）を実施するものである。
【００２４】
次に他の実施例として例えば夜間のバッチ処理時間を短縮したい場合を想定し、図６に示す様な手順で分析作業を進める。
【００２５】
先ず前記初期画面に於ける「ジョブ資産管理」を選択（ステップ６０）し、指定した過去数日分のジョブグループ毎の稼働状況をジョブスケジュールソースとジョブ稼働ログ情報をもとにグラフィカルに表示し、全体の処理時間が長く、且つ夜間遅くまで処理のかかっているジョブグループに着目し、着目日の当グループＩＤをクリック選択（ステップ６１）する。
【００２６】
この選択されたジョブグループの稼働状況はジョブ毎の処理時間として図７に示す様に表示される。
【００２７】
当ジョブグループの処理時間に対するクリティカルパスは、ＪＯＢ（Ａ）−ＪＯＢ（Ｃ）−ＪＯＢ（Ｆ）−ＪＯＢ（Ｇ）−ＪＯＢ（Ｊ）であり、これ等ジョブに対する時間短縮対策を見出すことが課題である。
【００２８】
これには▲１▼ジョブスケジュール上での対策と▲２▼ジョブへの対策とが考えられるが、ここではジョブへの対策を中心に説明する。
【００２９】
先の図７に於けるグラフィカルな表示画面でクリティカルパスとなっているジョブ・バーをクリック選択（ステップ６３）すると、当該ジョブ中のジョブステップ（ジョブメンバー）毎の処理時間がジョブ稼働ログ情報にもとづき表示される。
【００３０】
この操作に於いて最も処理時間の長いジョブステップを探索し、そのバーをクリック選択（ステップ６４）することにより当ジョブステップで扱う全てのファイルをジョブソース情報から特定し、各ファイルに関する詳細な定義情報を画面表示（ステップ６５）する。
【００３１】
これ等ファイル定義情報に於いて、例えば入力と出力を同一ボリューム上に配置していないか、ＳＯＲＴ−ＷＯＲＫなどについても調査し、同一ボリューム上に配置していれば、これをボリューム分散することにより処理時間短縮の検討（ステップ６６）を行う。
【００３２】
また、ファイル定義情報からデータのRead/Write単位であるブロック長が適切か等を調査（ステップ６７）する。
【００３３】
更に当ジョブステップがデータベース（ＤＢ）を使用する処理の場合には、サブレンジ分割（キーによるデータの分割）やインデックス見直し等の処理が可能か否かをＤＢソース情報をもとに表示し調査（ステップ６８）する。
【００３４】
この他、実施例として例えば初期画面で「ハード系資源管理」からエントリし、ＣＰＵの負荷が高い（所定値以上を指定）時刻を検索して、その時点で動作していたマルチジョブ群をピックアップし、これ等ジョブの中でジョブスケジュールを変更して負荷の軽減が可能か否かを調査するなど、これまでの実施例からも分かる様に、改善を要す問題の内容に応じてシステム（装置）へのエントリが多様であり、又エントリ後の一連の操作の流れも運用管理者の思考に沿った形で不定形（前に戻ることも可）に多種多量の情報の中から必要な情報のみ提供されるため、効率的な運用評価作業が可能となる。
【００３５】
尚、本発明に於けるコンピュータ処理は、コンピュータプログラムにより当該コンピュータの主記憶装置上で実行されるが、このコンピュータプログラムの提供形態は、当該コンピュータに接続された補助記憶装置をはじめ、フロッピーディスクやＣＤ−ＲＯＭ等の可搬型記憶装置やネットワーク接続された他のコンピュータの主記憶装置及び補助記憶装置等の各記録媒体に格納されて提供されるもので、このコンピュータプログラムの実行に際しては、当該コンピュータの主記憶装置上にローディングされ実行されるものである。
【００３６】
【発明の効果】
以上の説明から明らかなように本発明によれば、動的な資源別の稼働ログ情報が運用管理者の思考に沿って必要なもののみ時系列に統合された形で提供されると共に、関係する静的なソフト資源の定義体情報もそれに連携された形で提供されることにより従来の様な人的な各種情報の突き合わせ作業がなくなり、経験の浅い運用管理者でも容易に且つ短時間でシステムの運用評価を行うことが出来る様になる。
【００３７】
従って作業の効率化が図られると同時に、運用評価の作業プロセスを標準化することにより、より均一化された作業品質を保証することが可能となるという著しい工業的効果がある。
【図面の簡単な説明】
【図１】 本発明のシステム構成図
【図２】 本発明の処理手順概念図
【図３】 本発明の初期画面例
【図４】 磁気ディスクの容量的負荷の改善手順例
【図５】 ボリュームの使用状況
【図６】 ジョブグループの稼働時間短縮の改善手順例
【図７】 ジョブグループの稼働実績表示例
【符号の説明】
10 評価情報記憶手段
11 リクエスト手段
12 時系列編集手段
13 定義体編集手段
14 画面出力手段

Claims (1)

1. コンピュータシステムの運用評価を行わせるシステム運用管理のプログラムを記録した記録媒体であって、
   コンピュータに、
   前記コンピュータシステムの稼働ログ情報と各ジョブがどのファイルを使用するかに関する情報を含んだジョブソース情報を含む定義体情報とを評価情報記憶手段に記憶させるステップと、
   各ボリュームの最大容量に対する最低の空容量と空比率をボリューム一覧として表示した中から選択された第１のボリュームにつき、前記稼動ログから抽出した該第１のボリュームの使用状況を時系列に一覧表示するステップと、
   前記一覧表示した第１のボリュームの時系列の使用状況の中から選択された時間帯につき、前記稼動ログ情報を参照して、該特定された時間帯に該第１のボリューム上に存在していたファイルを使用容量と共に一覧表示するステップと、
   前記一覧表示したファイルの中から選択された第１のファイルにつき、前記特定された時間帯に前記第１のボリューム上に領域を確保して稼動していた稼動ジョブが、どのファイルを使用するかを前記ジョブソース情報から抽出して、該第１のファイルを使用するジョブを取得するステップと、
   前記取得したジョブの一覧を表示するステップと
   を実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images