Comments
Description
Transcript
CIM知識ベースを活用したシステム運用管理の インテリジェント化
NRI 技術創発
CIM知識ベースを活用したシステム運用管理の
インテリジェント化
An Intelligent System Monitoring Tool Utilizing the Common
Information Model as it’s Knowledge Base
田中 智
宇和田弘美
１．背景 ………………………………………………………………………79
２．最新の管理インターフェース標準 ……………………………………79
３．インテリジェント化 ……………………………………………………80
４．分類（Taxonomy）と意味（Ontology）の境界 ……………………81
５．障害メッセージ分析知識ベースとしてのCIM ………………………82
６．CIMの拡張（Extension）………………………………………………84
７．障害メッセージ分析システム …………………………………………85
８．プロセス連鎖情報による障害メッセージ因果関係把握方法 ………87
９．まとめ ……………………………………………………………………91
10．今後の課題 ………………………………………………………………91
要旨
システム運用分野の管理インターフェース標準としてCIM（Common Information Model）が業界
横断で構築され一部採用され始めている。CIMの枠組みで表現される障害の種類とそれらの因果関係
を抽出し、これを知識ベースとする障害分析システムを考案した。現在のCIM定義には不足があるの
で、この拡張も試みた。
結果、大規模化と普及に課題のある知識ベース構築を、高度な管理インターフェース標準CIMの枠
組みで行ないうることを示すことができた。
また、CIM知識ベースからは一般的な知識しか得られないので、対象システム固有の構成情報を動
的に取得し利用する方法も考案した。
キーワード：インテリジェントシステム、意味体系、オントロジー構築、CIM、CIM拡張、分類体系、システム管理、
DMTF、WBEM
Common Information Model (CIM) describes overall management information about a
network/enterprise environment. CIM has been shared among various system management
applications in business enterprises. We devised a new system for failure analysis by using the
CIM schema and found insufficient CIM applications.
As a result, it was proved that a knowledge-based system which needs to be enlarge the scale
and diffused can be established within the framework of CIM which has the advanced
knowledge.
We also devised how to dynamically collect data of specific system management because it can’
t
be collected by CIM knowledge-based data.
Keywords：Intelligent System Applications, Ontology, Ontology Development, CIM, CIM Extension, Taxonomy,
Systems Management, DMTF, WBEM
78
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
１．背景
理インターフェース標準がCIM（Common
エンタープライズ・システムでは、さまざ
Information Model）である。広範囲で本格
まなマルチベンダーによるシステム機器やソ
的な管理スキーマとして非営利団体 DMTF
フトウェアが相互に分散協調しており、その
（Distributed Management Task Force）に
管理／運用にかかわるコスト全体（TCO：
より1998年以降整備が続けられている。2003
Total Cost of Ownership）が増大している。
年４月30日にリリースされた2.7版では、オ
その主要な要因の一つは、マルチベンダーに
ブジェクト指向モデルで定義されたクラス数
よる管理インターフェースの不統一にある。
は既に1,200余となっている。
この解決のためには管理インターフェース
の統一が望まれる。そして、もしそれが実現
されれば、その管理インターフェース標準を
前提および基礎とする新たな運用管理のイン
テリジェント化も可能となる。
（３）CIM分類体系の高い抽象性
CIMはITの急激な変化にも耐えうる高い
抽象化を有した分類体系である。
分類のルートは、「管理要素：Managed
Element」である。その直下に「管理システ
２．最新の管理インターフェース標準
（１）管理インターフェースの要件
エンタープライズ・システムを構成するシ
ム要素：ManagedSystemElement」があり、
そ の 下 は 二 分 さ れ 、「 論 理 要 素 ： Logical
Element」と「物理要素：PhisicalElement」
ステム要素は急速に変容している。クライア
に な る 。 LogicalElementは 更 に Enabled
ント・サーバー形式を経て、現在サーバー側
LogicalElementつまり生起したり消滅する要
は更にフロントエンド、ミドルティア、バッ
素 の 分 類 に な る 。 こ の 下 に 、 Serviceや
クエンドの三層モデルへと分化している。ま
ServiceAccessPointなどが定義される。
た、ストレージもサーバーから独立しインテ
このような分類の抽象性は、主に分類体系の
リジェント化の一途を辿っている。
耐用年数を長くするためである（図１）。
標準化にあたりこのような急激な変化への
対応を十分考慮する必要がある。即ちITの
急激な変化にも耐えうる高い抽象化を有した
分類体系が求められている。
（４）CIMの利用
図２に示すように、WBEM（Web-based
Enterprise Management）なる統一管理の分
類体系基盤としてCIMは位置付けられている。
（２）DMTFによるCIM
上述要件に対応する最新のシステム機器管
既にWindows2000の標準機能として搭載さ
れている WMI（Windows Management
79
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
CIM Client
（管理アプリケーション）
ManagedElement
ManagedSystemElement
PhisicalElement
CIM Server（CIM-XML Protocol Adapter,
CIM-XML Indication Handler,
CIM Object Manager: CIMOM）
（入出力、メッセージ変換）
LogicalElement
EnabledLogical
Element
Service
ServiceAccess
Point
CIM Provider
（管理要素側の CIM 対応 I/F 機能）
・・・
Managed Element
（管理対象要素／ハード、ソフト）
・CIMは永続的に使えるモデル・スキーマを指向してい
るので抽象性が高い
・影付きの分類が比較的具体的な要素に相当する
図２ CIMに準拠したWBEM体系
図１ CIM分類体系の高い抽象性
スインフラの管理がCIMの基本思想だからで
Instrumentation） は 、 Microsoftに よ る
ある。言い換えると個々のシステムリソース
WBEMの実装である。他にもストレージや
の安定稼動やパフォーマンスが管理の対象で
LINUX 関連でWBEMは実装されている。
あって、ジョブがどこまで実行されたかの管
このように、システム機器やミドルソフト
のベンダーは、自社製品へのアクセスをCIM
スキーマに準拠して行なえるようにする。そ
理は手薄である。
従って、さまざまな見地から継続的にCIM
は拡張される必要があると言える。
の結果、全体として管理インターフェースが
統一されることになる。
３．インテリジェント化
（１）インテリジェント化の余地
（５）CIM分類体系の完成度
CIMのクラスにはDBMSの定義は含まれて
いる。しかし、CIMの最新バージョン2.8に
おいてもTPモニターは定義されていない。
一方、運用に関する管理コスト削減の方法
として、運用管理システムのより一層のイン
テリジェント化が考えられる。
すなわちさまざまなシステム機器の異なる
CIMは広範囲のシステム管理要素を扱いなが
インターフェース、メッセージの意味を、人
らもなお未完である。
間ではなく運用管理システムが解釈し対処す
また、ジョブスケジュール管理で扱われる
概念であるジョブフレーム、ジョブネットな
ることで運用の効率化を図るという考え方で
ある。
ども未定義である。これは、システムリソー
80
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
（２）知識ベースが必須
当然のことであるが、システムのインテリ
共通に利用される
オントロジー
?
ジェント化には、システム化の対象となるド
メインの知識ベースが必須である。一方近年
インターネット利用を中心としたヒューマン
インターフェースのインテリジェント化の要
インターフェースの
標準化
SNMP
MIB
CIM ?
図３ 標準化されるインターフェースと
されない？オントロジー
請から、いわゆる常識と呼ばれるより基本的
な知識を対象とする知識ベース（オントロジ
ー、メタ知識）が重要になっている。
その終了時期は明らかにされていない。
一方知識ベースとは独立した各種技術分野
におけるインターフェースの標準化は着実に
（３）実用的な知識ベースの姿が見えない
我々は2002年度下期に、セマンティック
Web技術の応用として、意味概念を表わす
進んでいる（図３）
。
実は、インターフェースの標準化と知識ベ
ースは無関係ではない。
辞書（オントロジー）を作成しWebサービ
スの結合を試み、個人業務範囲での有効性を
示した。
しかしアプリケーションの対象範囲を広げ
４．分類（Taxonomy）と意味（Ontology）
の境界
（１）分類（Taxonomy）
ると、必要な概念辞書の範囲が指数関数的に
システム管理におけるインターフェースの
広がり、概念辞書の実現性がたちまち危うく
標準化では、異なるベンダーによる管理対象
なる。
を扱う。そこでは、同類であれば同じ分類名
実用的な知識ベースには規模と複雑性の克
称で対象を識別し管理する。この点で、イン
服が欠かせないので、業界や社会の規模で取
ターフェースの標準化は分類の技術であると
り組むべきものである。しかし、大規模な特
言える。
定領域の知識ベースあるいはオントロジーに
分類技術の標準化で重要なのは、普及のコ
おいてそのような実用化レベルの規模で共有
ストをジャスティファイする分類体系の耐用
される業界横断あるいは社会的な活動は極め
年数である。
て少なく、実現の見通しが立っているとは言
い難い。
例えば一般常識を対象とするオントロジー
開発である有名なCycプロジェクトでさえ、
長い耐用年数を持つ分類体系を策定するに
は、その抽象度を高める必要がある。そのた
めにオブジェクト指向モデルが使われる。
CIMで定義されたクラスには、要素を示す
81
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
クラスと、要素間の関係を示すクラスがある。
る利用が考えられる。
その中には依存関係なども含まれる。例えば、
「プリントキューの動作は接続されているプ
リンタに依存している」、つまり「プリンタ
が停止していれば、プリントキューからプリ
ントジョブを渡すことができない」などの意
味関係が記述されている。
CIMは本来インターフェース標準を定める
分類 （Taxonomy）であるが、管理に必要
な意味も記述されている。
インターフェース標準のオブジェクト指向
５．障害メッセージ分析知識ベースとしての
CIM
（１）障害メッセージ（種類）とCIM
障害メッセージは、管理対象要素がある状
態から障害状態に遷移した際に、これを報
告／記録するために生成される。
一方CIMには各管理対象要素が定義されて
いる。定義構造は、クラス名、プロパティ、
モデルにおいては、上位階層は分類の抽象度
メソッドからなる。プロパティにはさまざま
を高めるために使われ、体系の下位レベルが
な属性が定義されるが、その中に管理対象要
個別のインターフェース識別に使用される。
素の状態を示す属性がある。
障害メッセージは、障害状態に遷移した際
（２）意味（Ontology）
に発生するので、CIMの障害状態を示す属性
一方、意味概念の体系化では、「同一であ
が障害メッセージの種類を示すことになる。
る」、「同類である」、「部分を成す」などが扱
例えば、CIM_Printerなるクラスの属性に
われる。関係記述が意味記述であり、体系全
DetectedErrorStateがあり、“No Paper”、
体がなんらかの意味に対応する。
“No Toner”などの障害状態を示す属性値が
あるので、Printerが“No Paper”や“No
（３）分類と意味の重なり
インターフェース標準は分類の体系なので、
Toner”に陥った場合に障害メッセージが発
生することになる。
体系全体が意味に対応することはない。しか
以下に管理対象要素の具体的なCIMクラス
し、個々の関係記述を見ればそこには何らか
例を示す。太字がクラス名を、斜体太字が属
の意味が記述されている。ここに分類記述と
性名に対応している。
意味記述の重なりがある。
CIM_PrintServiceについては、親の親ク
そこで、社会に共有されるインターフェー
ラスであるCIM_EnabledLogicalElementか
ス標準の体系に知識ベースの側面をより積極
ら継承するEnabledStateが状態を示す属性と
的に認めて、インテリジェント化の基礎とす
なる。
82
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
class CIM_Printer : CIM_LogicalDevice {
[ Values {“Other”, “Unknown”, “Idle”, “Printing”,
“Warmup”, “Stopped Printing”, “Offline”} ]
uint16 PrinterStatus;
[ Values {“Unknown”, “Other”, “No Error”, “Low
Paper”, “No Paper”, “Low Toner”, “No Toner”,
“Door Open”, “Jammed”, “Offline”, “Service
Requested”, “Output Bin Full”} ]
uint16 DetectedErrorState;
…
};
class CIM_PrintQueue : CIM_JobDestination {
boolean QueueEnabled;
boolean QueueAccepting;
…
};
class CIM_PrintService : CIM_Service {
…
};
class CIM_Service : CIM_EnabledLogicalElement {
…
};
class CIM_EnabledLogicalElement : CIM_LogicalElement
{
[ Values {“Unknown”, “Other”, “Enabled”,
“Disabled”, “Shutting Down”, “Not Applicable”,
“Enabled but Offline”, “In Test”, “Deferred”,
“Quiesce”, “Starting”, “DMTF Reserved”, “Vendor
Reserved” } ]
uint16 EnabledState = 5;
…
};
（２）障害メッセージ種類の抽出
CIMは、あいまいさの少ない形式性を有す
は一概（機械的）には識別できない。
また、状態を示す属性の各値のどれが障害
に相当するか機械的に識別できるようにはな
っていない。
従って、障害メッセージの種類を示すCIM
class CIM_Printer : CIM_LogicalDevice {
[ Values { Other , Unknown ,
Idle , Printing , Warmup , Stopped
Printing , Offline } ]
uint16 PrinterStatus;
[ Values { Unknown , Other , No
Error , Low Paper , No Paper , Low
Toner , No Toner , Door Open , Jammed ,
Offline , Service Requested , Output
Bin Full } ]
Stopped Printing
Offline
No Paper
No Toner
Door Open
Jammed
Offline
Service Requested
uint16 DetectedErrorState;
};
図４ CIMの属性から障害状態を抽出する
オブジェクトクラス属性の抽出には、人間の
判断が必要となる。
下図４に抽出例を図示する。
（３）障害メッセージ間の因果関係とCIM
CIMには、他のオブジェクト指向モデル同
様、事物一般を表わすクラスに加えて、その
クラス間の関係を表わすアソーシエイション
がある。アソーシエイションには、依存関係
を 示 す Dependencyや 構 成 関 係 を 示 す
Componentなどがある。クラス間に依存関
係や構成関係があれば、それはクラスで生じ
る定義ではあるが、完全な機械処理を可能と
る状態遷移の原因や影響先を示しているので、
するものではない。上記クラス定義例でもわ
障害メッセージ間の因果関係を示唆する情報
かるように、CIMで定義される各管理対象要
として利用できる。
素の状態を示す属性も、uint16型あるいは
例えば、CIM_Printerを依存先とし、CIM_
string型 の State、 Status属 性 の 他 に 、
PrintQueueを依存元とするCIM_Printer
boolean型の属性の一部が該当する。それら
ServicingQueueなる依存関係が定義されて
83
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
CIM_PrintService
CIM_PrintQueue
CIM_PrintJob
CIM_PrintSAP
CIM_Printer
CIM_PrintService
CIM_PrintQueue
CIM_PrintJob
CIM_PrintSAP
CIM_Printer
図５ CIMで定義されている依存関係の一部
いる。これによってCIM_Printerが原因にな
ってCIM_PrintQueueに影響が及ぶ可能性が
わかる。
以下に管理対象要素間関係の具体的なCIM
クラス例を示す。PrinterとPrintQueueおよ
びPrintQueueとPrintService間にある依存関
係（Dependency）である。
太字がクラス名を、斜体太字が属性名に対
応している。
class CIM_PrinterServicingQueue : CIM_Dependency {
CIM_Printer REF Antecedent;
CIM_PrintQueue REF Dependent;
};
class CIM_QueueForPrintService : CIM_Dependency {
CIM_PrintQueue REF Antecedent;
CIM_PrintService REF Dependent;
…
};
図６ CIMのDependency全体俯瞰図
図５はCIMに定義されている依存関係の一
部を図示したものである。楕円が要素を示す
クラスで、楕円間のアークが依存関係を示し
ている。
（矢印の頭が依存先）
（４）障害メッセージ間因果関係の抽出
障害メッセージ種類とは異なり、障害メッ
セージ間因果関係は、CIMのアソーシエイシ
ョンと呼ばれる要素間関係として、機械的に
図６はCIM version2.8 preliminaryから抽
抽出可能である。
出した依存関係（Dependency）の全体俯瞰
図である。図の細かいところはともかく、未
完とはいいながらCIMには相当数の依存関係
が定義されていることがわかる。
６．CIMの拡張（Extension）
CIMには既に多数の障害メッセージ分析知
識があるが、CIM自身がTPモニターなどを定
84
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
義していないので、CIMの拡張が必要となる。
TPモニターによるプロセス管理機能を拡
拡張手順は、まず（障害）状態を表わす属
張している。形式は、CIMがそもそも定義し
性を持つクラスを作る。次いで、障害の依存
て い る CIM_OperatingSystemと CIM_
関係を表わすクラス間関係のクラス（アソー
Processの関係に準拠し、TPモニター固有の
シエイション）を作ることになる。
特徴をクラス間関係であるNRI_TPMProcessに
ただしこの手順は、管理要素の全属性拡張
表現した。
ではなく、障害分析に必要な属性の拡張で
ある。
７．障害メッセージ分析システム
この章では、前述した拡張CIMを前提に
（１）CIM拡張（Extension）の具体例
以下に、TPモニターを対象とするCIM拡
張の具体例を示す。NRI_（影の付いた部分）
我々が開発した「CIMを知識ベースとする障
害メッセージ分析システム」を紹介する。
図７に全体構成を示す。
が拡張クラスとなる。
class CIM_Process : CIM_EnabledLogicalElement {
[Values {“Unknown”, “Other”, “Ready”,
“Running”, “Blocked”, “Suspended Blocked”,
“Suspended Ready”, “Terminated”, “Stopped”,
“Growing", “Ready But Relinquished Processor”,
“Hung”} ]
uint16 ExecutionState;
…
};
class NRI_TPMProcess : CIM_Component {
NRI_TPMonitor REF GroupComponent;
CIM_Process REF PartComponent;
[Values {...”, ...
“Can NOT complete within Timeout Period”,
“Failed”,
... , “...”} ]
boolean ProcessExecutionState;
[Values {“...”, ...
“Shutting Down”,
... , “..."} ]
boolean ProcessEnablesState;
…
};
class NRI_TPMonitor : CIM_EnabledLogicalElement
{
…
};
①知識抽出機能
（CIMから知識を抽出する）
障害メッセージ分析知識
（CIMから抽出した知識）
現行システム機器
（CIM未対応）
②メッセージ変換機能
（現行機器メッセージを
CIM準拠に変換）
対応表
メッセージ比較機能
（因果関係有無のマッチング）
③メッセージ分析機能
（人の判断を支援する
分析機能）
画面
図７ 障害メッセージ分析システムの全体構成
85
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
図９ CIM対応メッセージ表示画面
図８ メッセージ表示画面
（１）全体構成
①CIMからの知識抽出機能
CIMのXML形式を入力として、CIMから
障害種類とその依存関係などを抽出するため
③メッセージ分析機能
（障害）メッセージ読み込みごとに、CIM
障害メッセージおよびその因果関係と比較し、
一致するごとに図示する。
の支援環境。
②メッセージ変換機能
CIM に対応していないシステム機器から
の現行障害メッセージをCIM対応障害メッセ
ージ変換に変換する部分。
現行障害メッセージとCIM障害メッセージ
との対応表を事前に作ることになる。
CIMが各システム機器、ミドルソフトウェ
（２）画面例
①メッセージ表示画面
現行の運用監視コンソールの画面には、相
互関連を示す情報がなく、次から次へと（障
害）メッセージが表示されていく（図８）。
②CIM対応メッセージ表示画面
現行障害メッセージとCIMスキーマから抽
アベンダーに普及するまで当面は、利用者側
出した障害メッセージの対応表画面（図９）。
で対応表を作成する。利用者側として一般企
③メッセージ分析画面
業は考え難いが、運用ツールベンダーにはイ
ンセンティブがある。
あるいは、各システム機器ベンダーに、先
ず（障害）メッセージをCIM対応にするよう
現行の運用監視コンソールに対応し、（障
害）メッセージが到着する毎に障害メッセー
ジを点で表示する。横軸はCIM分類、縦軸は
時間。
に要請する。近い将来CIMが普及するものと
CIM対応メッセージは、点をCIM要素クラ
考えられるので、各ベンダーにとってもイン
ス名と該当状況コメントに置き換えて、該当
センティブがあると考えられる。
する分類の下に表示する。
86
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
図10 CIM対応メッセージ表示画面
また、CIMから得られた依存関係に該当す
る場合には、これを矢印で結んで図示する
図11 メッセージ因果関係説明画面
（図10）。
④メッセージ因果関係説明画面
因果関係の矢印結合部分をクリックすると、
CIMの関係定義を表示する（図11）。
を考える上では、一般情報（知識）と個別情
報（知識）の両方がともに欠かせない。
一般情報（知識）は標準化可能であるが、
個別情報（知識）は標準化できない。そこで、
８．プロセス連鎖情報による障害メッセージ
因果関係把握方法
個別情報（知識）については、全く別のアプ
ローチが必要となる。
（１）一般情報（知識）だけでなく個別情報
（知識）も必要
情報や知識には、一般情報（知識）と個別
情報（知識）の二通りがある。
例えば、「プリントジョブは、プリントキ
（２）障害、障害メッセージとプロセス
①障害
システム機器、ソフトの障害は、“ケーブ
ル断線”から“OSメモリリーク”などさま
ューに蓄えられて、順次プリンタで処理され
ざまである。
る」は一般知識で、「実際の現場には、プリ
②障害メッセージ
ンタが５台あって、プリントキューを司るサ
エンタープライズ・システムを構成する要
ーバーは３台で、プリンタとの対応は…であ
素もさまざまにあるが、メッセージはほとん
る」などの情報は個別情報となる。
ど何らかのソフトウェアからである。例えば、
システム管理／運用のインテリジェント化
OS、DBMSなどのミドルウェア、アプリケ
87
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
表１ プロセス間連鎖の種類
定 義
ジョブ
プログラム
プロセス
プロセス
技 術
同期型
プロセス連鎖
プロセス間のリアルタ
イムなコミュニケーシ
ョンによるプロセス間
の連鎖
pipes, message,
semaphores,
sharedmemory,
socketsなど
非同期型
プロセス連鎖
外部媒体に記録するデ
ータを介してコミュニ
ケーションする非同期
なプロセスの連鎖
ファイルあるい
はデ−タベース
のレコードなど
ミドルソフト
OS
プロセス
ファイル
プロセス
プロセス
プロセス
プロセス
プロセス
図12 一連のプログラム（ジョブ）はプロセス
連鎖からなる
トキューはいずれ一杯になり、プリントサー
ーションプログラム、機器の組み込みソフト
ビスは停止する。この因果関係は、CIMから
ウェアなどからである。
一般的な知識として抽出できる。
③プロセス
ソフトウェアがランしている状態の基本単
位はプロセスになる。
OSもさまざまなプロセスからなり、ブー
トプロセスから多数のプロセスが派生してい
る。また、シェルのようなコマンド受付プロセ
しかし、複数のプリンタや複数のサーバ
ー・クライアントが接続されているネットワ
ーク環境では、お互いに独立した複数の障害
を区別する必要がある。それには、その環境
固有の構成情報が必要である。
エンタープライズ・システムの現場実態を、
スがアプリケーションプロセスを発生させる。
正確かつ詳細に反映した構成情報が常に利用
アプリケーションプロセスは、自身が親プ
できれば良い。しかし現実にはそのような情
ロセスとなって子プロセスを派生させたり、
あるいは別途生成されたプロセスにサービス
報の存在は期待できない。
そこで、構成情報あるいはこれに相当する
を依頼したりしてジョブを遂行する。このよ
情報取得の方法を考えなくてはならない。
うな形態を、同期型プロセス連鎖と呼ぶこと
⑤プロセス連鎖と構成情報
にする。
一方、ファイルやDBMSなどを介して、ジ
ョブスケジューラーによって複数のジョブ
（プロセス）が連鎖する場合がある。これを
ジョブがプロセスの連鎖であることを述べ
た。また、システム障害は何らかのプロセス
によって報告されることも述べた。従って、
プロセス連鎖が把握され、障害メッセージに
非同期型プロセス連鎖と呼ぶ（表１）
。
発信プロセスの識別情報が付帯されれば、障
④障害メッセージの因果関係と構成情報
害メッセージ間の因果関係の把握になる。
例えば、プリント量の多い環境で、プリン
同じノード内であれば、そのOSがプロセ
タに紙詰まりのような障害があれば、プリン
ス間関係を把握している。ノード間通信であ
88
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
っても、送信側、受診側双方ともお互いのプ
みデリミタ単位に連鎖情報を付帯する。プロ
ロセスを認識している。
セス全般は、障害ログ書き出し先としてこの
また、ファイル渡しのような非同期な連鎖
であっても、ジョブスケジューラに連鎖の対
が識別できる情報が記載されている（図12）
。
特定ファイルを使う。
②非同期型連鎖
非同期型プロセス連鎖は、ジョブスケジュ
障害
（３）プロセス連鎖情報把握方法
以下に示す方法は一例である。
プロセス
プロセス
プロセス
①同期型連鎖
プロセス
同期型プロセス連鎖は大きく二種類に分け
障害
メッセージ
ることができる。一つは親子プロセス連鎖で
ある。もう一つはプロセス間通信による連鎖
特定ファイル
WRITE文
である。
また、同一ノード内の連鎖と、異なるノー
関連同期プロセス連鎖情報
ド間連鎖の二通りがある。
一方、ノードの中に注目すると、OSが基
礎にあり、TPモニタなどのミドルソフトが
特定ファイル
間にあって、その上にアプリケーションがあ
る。
関連非同期プロセス連鎖情報
以上を踏まえて、同期型プロセス連鎖情報
の把握方法として例えば次の方法が考えられ
る。
特定ファイル
WRITE文
OS、ミドル、アプリケーションなどプロ
セス全般が障害ログを書き出す際に、自身の
「ノード名＋プロセスID」および自身が関連
障害
メッセージ
ジョブスクリプト
する全ての同期型プロセス連鎖について「連
鎖種別、相手側の送信／受信区別、相手側の
プロセス
ノード名＋プロセスID」が付帯して記録さ
障害
れるようにする。この際OSは特定の指定さ
れたファイルへの書き込みについて、書き込
受け渡しファイル
プロセス
プロセス
図13 プロセス連鎖情報把握と障害メッセージ
全体像
89
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
ケジューラーなどは、
ジョブ
プログラム
そのスクリプトに書か
プロセス
プロセス
れたプログラムを起動
プロセス
ファイル
するので、実行時の該
ミドルソフト
OS
プロセス
プロセス
プロセス
当するプロセスIDを知
プロセス
プロセス
りうる。従って、プロ
セスIDでの連鎖情報を
得ることができる。
③全体像
機器ソフトに
障害発生
機
器
、
ソ
フ
ト
の
ビ
ュ
ー
同期連鎖、非同期連
鎖合わせてプロセス連
運用管理対象の
ログファイル
システム機器、ソフト
（稼動状況記録）
鎖情報が取得され、障
害メッセージ群の相互
関連情報となる（図
プロセス連鎖情報
で関連付けられた
障害メッセージ群
運用管理
コンソール
13）
。
この仕組みによって、
・サービスを提供する
サ
ー
ビ
ス
の
ビ
ュ
ー
ジョブの単位に、その
顧客データへの
顧客サービスへの
影響？
影響？
プロセス連鎖として障
害状況が把握できる。
・ジョブ単位に把握で
図14 プロセス連鎖情報取得による運用管理のインテリジェント化
きるので、サービス提
供から見た判断が容易
ーラーやジョブスクリプトなどで明示的に、
送信側プログラム、受信側プログラム、およ
び送受信用ファイルが指定されている。
従って、ジョブスケジューラーやジョブス
クリプトから非同期連鎖を、プログラム名の
になる。
・障害の真の原因に最も近いプロセスが即
座に把握できる。関連する詳細ログ情報
にもプロセス連鎖情報があるので、真の
原因把握が容易になる（図14）
。
連鎖情報として得ることができる。ジョブス
90
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
CIM知識ベースを活用したシステム運用管理のインテリジェント化
９．まとめ
CIMは障害メッセージ分析の知識ベースと
・特定OSやクラスタOSでのプロセス連鎖
情報取得実現。
して利用できる。管理インターフェース標準
の拡張が、同時に知識ベースの拡張にもなれ
参考文献─────────────────────
［１］DMTF Home Page, CIM Schema: Version 2.8
る。
（Preliminary）
プロセス連鎖情報を障害メッセージに付加
することにより、システム構成情報が動的に
把握され、サービスおよびシステム機器運用
いずれも観点からも、障害分析対応の速度と
確度が向上する。
http://www.dmtf.org/standards/cim/cim_
schema_v28
［２］DMTF Home Page, DMTF White Papers
http://www.dmtf.org/standards/published_
documents#whitepapers
［３］DMTF Home Page,“CIM - The Common
Information Model DMTF Tutorial”
１
０．今後の課題
以下が考えられる。
・障害分析知識ベースとしての要件を更に
http://www.dmtf.org/standards/cim/DMTFCIMTutorial.pdf
［４］DMTF Home Page, DMTF Education
http://www.dmtf.org/education
明らかにし、既存のCIMや今後の拡張を
［５］OpenCyc.org Home Page
反映されるようにDMTFへの働きかけ。
http://www.opencyc.org/
・障害メッセージ形式化への提言。
91
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2004 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.