application dependency discovery managern...本書は、 ibm tivoli application dependency discovery...

Tivoli Application Dependency DiscoveryManagerバージョン 7.3

管理者ガイド

IBM

注記

本書および本書で紹介する製品をご使用になる前に、 307 ページの『特記事項』に記載されている情報をお読みください。

本書は、IBM Tivoli Application Dependency Discovery Manager (製品番号 5724-N55) バージョン 7 リリース 3および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

本書は下記原典を翻訳したものです。

原典： Tivoli Application Dependency Discovery ManagerVersion 7.3Administrator's Guide

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

© Copyright IBM Corporation 2006, 2018.

目次

表 . . . . . . . . . . . . . . . . . v

この情報について . . . . . . . . . . viiこのインフォメーション・センターで使用される規則 . . . . . . . . . . . . . . . . . vii用語と定義 . . . . . . . . . . . . . . viii

管理 . . . . . . . . . . . . . . . . 1TADDM の概要 . . . . . . . . . . . . . 1

ディスカバリー・プロセスの概要 . . . . . . 3トポロジー構築プロセスの概要 . . . . . . . 17ログ・ファイルおよびロギング . . . . . . . 18

環境の保護 . . . . . . . . . . . . . . 18構成アイテムへのユーザー・アクセスのコントロール . . . . . . . . . . . . . . . . 18ロックアウト . . . . . . . . . . . . . 22暗号化 . . . . . . . . . . . . . . . 23FIPS 準拠 . . . . . . . . . . . . . . 24SP800-131 への準拠 . . . . . . . . . . 26同期サーバー・デプロイメントのセキュリティー 26ストリーミング・サーバー・デプロイメントのセキュリティー . . . . . . . . . . . . . 28LDAP の構成 . . . . . . . . . . . . 28WebSphere Federated Repositories の構成 . . . 29Microsoft Active Directory 用の構成 . . . . . 36TADDM Web サービスの保護 . . . . . . . 37TADDM での使用を目的としたカスタマイズしたSSL 証明書のインストール . . . . . . . . 38

TADDM サーバーの管理 . . . . . . . . . . 40TADDM サーバーの状況の確認 . . . . . . 40TADDM サーバーの始動 . . . . . . . . . 42TADDM サーバーの停止 . . . . . . . . . 43データのバックアップ . . . . . . . . . . 44データの復元 . . . . . . . . . . . . . 44TADDM サーバー間でのディスカバリー・スコープ、ディスカバリー・プロファイル、およびカスタム・サーバー・テンプレートのコピー . . . . 45ディスカバリー管理コンソールのデプロイ . . . 46TADDM 通信の構成 . . . . . . . . . . 47TADDM サーバー・プロパティーのリファレンス 67データ保全性の検証 . . . . . . . . . . 110資格情報キャッシュの管理 - cachemgr ユーティリティー . . . . . . . . . . . . . 114

ディスカバリーの準備 . . . . . . . . . . 116ユーザー・ログオン ID の構成 . . . . . . 117代替ディスカバリー方式の構成 . . . . . . 117ディスカバリーのレベルの構成 . . . . . . 127

Windows システムのディスカバリーの構成 . . 137プレースホルダーのディスカバリーの構成 . . . 146資格情報なしのレベル 3 アプリケーション・サーバーの作成 . . . . . . . . . . . . 148ロケーション・タグ付けの構成 . . . . . . 149

保守とチューニング . . . . . . . . . . . 152バルク・ロード・パラメーターのチューニング 152データベース保守 . . . . . . . . . . . 154ディスカバリー・パフォーマンスのチューニング 166Java 仮想マシン: IBM パラメーターのチューニング . . . . . . . . . . . . . . . 169Java 仮想マシン・プロパティーのチューニング 171ネットワークのチューニング . . . . . . . 171DNS のチューニング . . . . . . . . . . 172同期サーバーのチューニング . . . . . . . 173Windows システムのチューニング . . . . . 173

レポート作成 . . . . . . . . . . . . . 173外部レポート・ビューアー . . . . . . . . 174JSP レポート・ビューアー . . . . . . . . 176Tivoli Common Reporting でのレポート作成 178BIRT を使用したレポート . . . . . . . . 194

TADDM と他の Tivoli 製品との統合 . . . . . 217サポートされるバージョン . . . . . . . . 217OSLC 自動化を通じた TADDM と IBM TivoliMonitoring の統合 . . . . . . . . . . 219OSLC 自動化を介した TADDM の他の製品への統合 . . . . . . . . . . . . . . . 231TADDM と IBM Tivoli Monitoring (旧方式)との統合 . . . . . . . . . . . . . . 235コンテキスト・メニュー・サービスおよびデータ統合サービスの構成アイテムの登録 . . . . . 239Discovery Library ストアの作成 . . . . . . 242ランチ・イン・コンテキストの構成 . . . . . 244外部システムへの変更イベントの送信 . . . . 247IBM Tivoli Workload Scheduler を使用したジョブのスケジューリング . . . . . . . . . 262TADDM と IBM Tivoli Business ServiceManager との統合 . . . . . . . . . . 264TADDM と Jazz for Service Management との統合 . . . . . . . . . . . . . . . 265Tivoli Directory Integrator . . . . . . . . 279以前のバージョンとのビジネス・エンティティーの互換性 . . . . . . . . . . . . . . 280BigFix の統合 . . . . . . . . . . . . 281

特記事項 . . . . . . . . . . . . . . 307商標 . . . . . . . . . . . . . . . . 308

© Copyright IBM Corp. 2006, 2018 iii

iv Application Dependency Discovery Manager: 管理

表1. ディスカバーされるエンティティーとその説明 22. サービスのデフォルトのインターフェース設定 473. サービスのデフォルトのインターフェース設定 474. ping センサーおよびポート・センサーのデフ

ォルトのポート . . . . . . . . . . . 495. ドメイン・サーバーのパブリック接続サービス

のデフォルトのホスト設定 . . . . . . . 516. ドメイン・サーバーのパブリック接続サービス

のデフォルトのポート設定 . . . . . . . 527. ドメイン・サーバーのローカル接続サービスの

デフォルトのホスト設定 . . . . . . . . 528. データベース・サーバーとドメイン・サーバー

の間の通信。 . . . . . . . . . . . . 529. ディスカバリー管理ポータル、API クライアン

ト、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーの間の通信。 . . . . . . . . . 53

10. アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信。 . . . . . . . . . . 53

11. ドメイン・サーバーのローカル接続の通信構成 5412. 1 次ストレージ・サーバー、2 次ストレージ・

サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのホスト設定 . . . . . . . . . . . . . . . 55

13. 1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのポート設定 . . . . . . . . . . . . . . . 55

14. 1 次ストレージ・サーバー、および 2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのホスト設定 . . . . . . . . 55

15. 1 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定 . . . . . 56

16. 2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定 . . . . . 56

17. 1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのローカル接続サービスのデフォルトのホスト設定 . . . . . . . . . . . . . . . . 56

18. ストリーミング・サーバー・デプロイメントでのサーバー間接続の通信構成。 . . . . . . 57

19. ディスカバリー管理ポータル、API クライアントと Web ポータルおよびデータ管理ポータルのクライアント、ならびに TADDM サーバーの間の通信。 . . . . . . . . . . . . 58

20. アンカーとゲートウェイ、およびディスカバリー・サーバーの間の通信。 . . . . . . . 60

21. ストリーミング・サーバー・デプロイメントでのローカル接続の通信構成。 . . . . . . . 60

22. ドメイン・サーバー、および同期サーバーのパブリック接続サービスのデフォルトのホスト設定 . . . . . . . . . . . . . . . . 62

23. ドメイン・サーバーのパブリック接続サービスのデフォルトのホスト設定 . . . . . . . 62

24. 同期サーバーのパブリック接続サービスのデフォルトのポート設定 . . . . . . . . . . 62

25. ドメイン・サーバー、および同期サーバーのサーバー間接続サービスのデフォルトのホスト設定 . . . . . . . . . . . . . . . . 63

26. ドメイン・サーバーのサーバー間接続サービスのデフォルトのポート設定 . . . . . . . 63

27. 同期サーバーのサーバー間接続サービスのデフォルトのポート設定 . . . . . . . . . . 63

28. ドメイン・サーバー、および同期サーバーのローカル接続サービスのデフォルトのホスト設定 . 64

29. 同期サーバー・デプロイメントでのサーバー間接続の通信構成。 . . . . . . . . . . 64

30. ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーおよび同期サーバーの間の通信。 . . 65

31. アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信。 . . . . . . . . . . 66

32. 同期サーバー・デプロイメントでのローカル接続の通信構成。 . . . . . . . . . . . 66

33. makeASDScriptPackage コマンドで使用されるセンサー名。 . . . . . . . . . . . 119

34. SSH 鍵 . . . . . . . . . . . . . 13035. hierarchyDomain 属性値と hierarchyType 属

性値 . . . . . . . . . . . . . . 14636. バッファー・プール・サイズの指針

(db_cache_size) . . . . . . . . . . . 16537. モニター範囲レポート . . . . . . . . 19938. 定義済みセンサー・レポート . . . . . . 20039. 定義済みスナップショット・レポート 20340. サポートされる製品バージョン . . . . . 21841. OSLC 自動化を通じた TADDM と IBM

Tivoli Monitoring の統合 . . . . . . . 22042. OSLC を介したディスカバリーに関する詳細

が記載されているトピック。 . . . . . . 23243. 使用する統合機能に対応するユーザー・タス

ク . . . . . . . . . . . . . . . 23544. IBM Tivoli Monitoring を使用したディスカ

バリーに関する詳細情報が含まれているトピック . . . . . . . . . . . . . . 237

45. 変更イベントに関する詳細情報を含むトピック . . . . . . . . . . . . . . . 238

46. ランチ・イン・コンテキストに関する詳細情報を含むトピック . . . . . . . . . . 238

© Copyright IBM Corp. 2006, 2018 v

47. 有効な graph 値および各値と guid パラメーターの関係 . . . . . . . . . . . . 246

48. TADDM MQL 照会の演算子名。 . . . . . 25049. 状態コード . . . . . . . . . . . . 26550. . . . . . . . . . . . . . . . . 29251. . . . . . . . . . . . . . . . . 29252. . . . . . . . . . . . . . . . . 29353. . . . . . . . . . . . . . . . . 29354. . . . . . . . . . . . . . . . . 29455. . . . . . . . . . . . . . . . . 29556. . . . . . . . . . . . . . . . . 29657. . . . . . . . . . . . . . . . . 29658. . . . . . . . . . . . . . . . . 29759. . . . . . . . . . . . . . . . . 297

60. . . . . . . . . . . . . . . . . 29761. . . . . . . . . . . . . . . . . 29862. . . . . . . . . . . . . . . . . 29963. . . . . . . . . . . . . . . . . 29964. . . . . . . . . . . . . . . . . 29965. . . . . . . . . . . . . . . . . 30066. . . . . . . . . . . . . . . . . 30167. . . . . . . . . . . . . . . . . 30268. . . . . . . . . . . . . . . . . 30269. . . . . . . . . . . . . . . . . 30270. . . . . . . . . . . . . . . . . 30371. . . . . . . . . . . . . . . . . 30372. . . . . . . . . . . . . . . . . 305

vi Application Dependency Discovery Manager: 管理

この情報について

この PDF 文書バージョンの目的は、インフォメーション・センターの関連トピックを印刷可能な形式で提供することです。

このインフォメーション・センターで使用される規則IBM® Tivoli Application Dependency Discovery Manager (TADDM) の資料では、特定の規則が使用されます。この規則は、オペレーティング・システムに依存する変数とパス、COLLATION_HOME ディレクトリー、および collation.propertiesファイルの場所を示すために使用されます。このファイルは、TADDM の資料全体(メッセージ内を含む) を通じて参照されます。

オペレーティング・システムに依存する変数およびパス

このインフォメーション・センターでは、環境変数の指定およびディレクトリーの表記に UNIX 規則が使用されます。

Windows コマンド行を使用する場合は、環境変数の $variable を %variable% に置き換え、ディレクトリー・パスのスラッシュ (/) を円記号 (¥) に置き換えてください。

Windows システムで bash シェルを使用している場合は、UNIX の規則を使用できます。

COLLATION_HOME ディレクトリー

TADDM ルート・ディレクトリーは、COLLATION_HOME ディレクトリーとも呼ばれます。

AIX® または Linux などのオペレーティング・システムでは、TADDM をインストールするデフォルトのロケーションは /opt/IBM/taddm ディレクトリーです。したがって、この場合の $COLLATION_HOME ディレクトリーは /opt/IBM/taddm/dist になります。

Windows オペレーティング・システムでは、TADDM をインストールするデフォルトのロケーションは c:¥IBM¥taddm ディレクトリーです。したがって、この場合の %COLLATION_HOME% ディレクトリーは、c:¥IBM¥taddm¥dist になります。

collation.properties ファイルのロケーション

collation.properties ファイルには TADDM サーバーのプロパティーが含まれていて、各プロパティーに関するコメントが含まれています。このファイルは$COLLATION_HOME/etc ディレクトリー内にあります。

© Copyright IBM Corp. 2006, 2018 vii

用語と定義IBM Tivoli Application Dependency Discovery Manager (TADDM) の重要な概念について理解するには、以下の用語と定義のリストを参照してください。

アクセス・コレクション構成アイテムおよび構成アイテムを変更する許可へのアクセスを制御するために使用するコレクション。アクセス・コレクションは、データ・レベル・セキュリティーが有効になっている場合にのみ作成できます。

非同期ディスカバリーTADDM で、TADDM サーバーが直接アクセスできないシステムをディスカバーするために、ターゲット・システムでディスカバリー・スクリプトを実行する操作です。このディスカバリーは、標準的な資格情報付きのディスカバリーとは別に手動で実行されるため、「非同期」と呼ばれます。

ビジネス・アプリケーション内部または外部で使用したり、他のビジネス・アプリケーションと併用したりできるビジネス機能を提供するコンポーネントの集合。

CI 「構成アイテム」を参照。

コレクションTADDM において、構成アイテムのグループ。

構成アイテム (CI)構成管理の制御対象であるために正式な変更制御に依存する IT インフラストラクチャーのコンポーネント。 TADDM データベース内の各 CI には、永続オブジェクトがあり、それには変更履歴が関連付けられています。 CIの例としては、オペレーティング・システム、L2 インターフェース、データベース・バッファー・プールのサイズなどがあります。

資格情報を持つディスカバリー以下の項目に関する詳細情報をディスカバーする TADDM センサーによるスキャン。

v ランタイム環境内の各オペレーティング・システム。このスキャンは、レベル 2 ディスカバリーとも呼ばれ、オペレーティング・システムの資格情報を必要とします。

v ランタイム環境で使用される、アプリケーション・インフラストラクチャー、デプロイ済みソフトウェア・コンポーネント、物理サーバー、ネットワーク・デバイス、仮想システム、およびホスト・データ。このスキャンは、レベル 3 ディスカバリーとも呼ばれ、オペレーティング・システムの資格情報とアプリケーションの資格情報の両方を必要とします。

資格情報なしのディスカバリーランタイム環境におけるアクティブ・コンピューター・システムに関する基本情報をディスカバーする TADDM センサー・スキャン。このスキャンは、レベル 1 ディスカバリーとも呼ばれ、資格情報を必要としません。

データ管理ポータルTADDM データベースのデータを表示および操作するための、TADDM のWeb ベース・ユーザー・インターフェース。このユーザー・インターフェースは、ドメイン・サーバー・デプロイメントと同期サーバー・デプロイメ

viii Application Dependency Discovery Manager: 管理

ント、およびストリーミング・サーバー・デプロイメントの各ストレージ・サーバーで使用できます。ユーザー・インターフェースは、すべてのデプロイメントでほとんど同じです。ただし、同期サーバー・デプロイメントには、ドメインの追加と同期を行うための機能が追加されています。

ディスカバー・ワーカー・スレッドTADDM において、センサーを実行するスレッド。

ディスカバリー管理コンソールディスカバリーを管理するための TADDM クライアント・ユーザー・インターフェース。このコンソールは製品コンソールとも呼ばれます。ドメイン・サーバー・デプロイメントと、ストリーミング・サーバー・デプロイメントのディスカバリー・サーバーで使用できます。このコンソールの機能は、これらの両方のデプロイメントで同じです。

ディスカバリー・サーバーストリーミング・サーバー・デプロイメントでセンサーを実行するが、専用のデータベースを持たない TADDM サーバー。

ドメインTADDM において、企業またはその他の組織のインフラストラクチャーの論理的なサブセット。ドメインは、組織的、機能的、または地理的な境界を示します。

ドメイン・サーバー専用のデータベースを持ち、ドメイン・サーバー・デプロイメントでセンサーを実行する TADDM サーバー。

ドメイン・サーバー・デプロイメントドメイン・サーバーが 1 台の TADDM デプロイメント。ドメイン・サーバー・デプロイメントは、同期サーバー・デプロイメントの一環として行うこともできます。

ドメイン・サーバー・デプロイメントでは、以下の TADDM サーバー・プロパティーを次の値に設定する必要があります。

com.collation.cmdbmode=domain

ランチ・イン・コンテキストシングル・サインオンを使い、ユーザーが作業を継続できるように適切な時点で適切な位置にターゲットの UI を表示することにより、ある Tivoli® 製品の UI から (別のコンソールまたは同じコンソール/ポータル・インターフェースのいずれかにある) 別の Tivoli 製品の UI にシームレスに移行することを示す概念。

レベル 1 ディスカバリーランタイム環境におけるアクティブ・コンピューター・システムに関する基本情報をディスカバーする TADDM センサー・スキャン。このスキャンは、資格情報を必要としないことから、資格情報なしのディスカバリーとも呼ばれます。このスキャンでは、スタック・スキャン・センサーおよびIBM® Tivoli® Monitoring スコープ・センサーが使用されます。レベル 1ディスカバリーは非常に簡単なものです。ディスカバーした各インターフェースのホスト名、オペレーティング・システム名、IP アドレス、完全修飾ドメイン名、およびメディア・アクセス制御 (MAC) アドレスのみが収集されます。また、MAC アドレスのディスカバリーは、Linux on System

この情報について ix

z® システムと Windows システムに限定されます。レベル 1 ディスカバリーは、サブネットをディスカバーしません。ディスカバーされた IP インターフェースのうち、レベル 2 またはレベル 3 ディスカバリーでディスカバーされた既存のサブネットに属さないものがあれば、collation.properties ファイル内のcom.collation.IpNetworkAssignmentAgent.defaultNetmask プロパティーの値に基づいて新規サブネットが作成されます。

レベル 2 ディスカバリーランタイム環境における各オペレーティング・システムに関する詳細情報をディスカバーする TADDM センサー・スキャン。このスキャンは、資格情報付きのディスカバリーとも呼ばれ、オペレーティング・システムの資格情報を必要とします。レベル 2 ディスカバリーでは、実行中の各アプリケーションに関連するアプリケーション名、オペレーティング・システム名、およびポート番号が収集されます。アプリケーションが別のアプリケーションに TCP/IP 接続を確立した場合、この情報は依存関係として収集されます。

レベル 3 ディスカバリーランタイム環境で使用されるアプリケーション・インフラストラクチャー、デプロイ済みのソフトウェア・コンポーネント、物理サーバー、ネットワーク・デバイス、仮想システム、ホスト・データに関する詳細情報をディスカバーする TADDM センサー・スキャン。このスキャンは、資格情報付きのディスカバリーとも呼ばれ、オペレーティング・システムの資格情報とアプリケーションの資格情報の両方を必要とします。

マルチテナントTADDM において、TADDM インストール済み環境が 1 つであるサービス・プロバイダーまたは IT ベンダーが、複数の顧客環境をディスカバーする場合に使用される用語。そのサービス・プロバイダーまたは IT ベンダーは、すべての顧客環境のデータを表示できますが、各顧客環境の内部では、ユーザー・インターフェースやその顧客環境内のレポートに表示できるデータは、それぞれの顧客に固有のデータのみになります。

製品コンソール「ディスカバリー管理コンソール」を参照。

スクリプト・ベースのディスカバリーTADDM において、センサーが非同期ディスカバリーをサポートするために提供しているものと同じセンサー・スクリプトを、資格情報付きのディスカバリーで使用すること。

SE 「サーバー等価物」を参照。

サーバー等価物 (SE)サーバー・ソフトウェア (データベース、Web サーバー、アプリケーション・サーバーなど) がインストールされている、コンピューター・システム(標準の構成、オペレーティング・システム、ネットワーク・インターフェース、ストレージ・インターフェースを持つもの) として定義される IT インフラストラクチャーの典型的単位。サーバー等価物の概念には、サーバーの最適な動作のためにサービスを提供するネットワーク、ストレージ、およびその他のサブシステムも含まれます。サーバー等価物は、オペレーティング・システムによって異なります。

x Application Dependency Discovery Manager: 管理

オペレーティング・システム CI の概数

Windows 500

AIX 1000

Linux 1000

HP-UX 500

ネットワーク・デバイス 1000

ストレージ・サーバーディスカバリー・サーバーから受信したディスカバリー・データを処理してTADDM データベースに保管する TADDM サーバーです。 1 次ストレージ・サーバーは、ディスカバリー・サーバーと他のすべてのストレージ・サーバーを調整し、ストレージ・サーバーとして機能します。 1 次ストレージ・サーバーではないストレージ・サーバーはすべて 2 次ストレージ・サーバーと呼ばれます。

ストリーミング・サーバー・デプロイメント1 次ストレージ・サーバーが 1 台で、ディスカバリー・サーバーが少なくとも 1 台の TADDM デプロイメント。このタイプのデプロイメントでは、オプションの 2 次ストレージ・サーバーを 1 つ以上組み込むこともできます。 1 次ストレージ・サーバーおよび 2 次ストレージ・サーバーは、1 つのデータベースを共有します。ディスカバリー・サーバーには、データベースがありません。

このタイプのデプロイメントでは、ディスカバリー・データのフローは複数のディスカバリー・サーバーから TADDM データベースに向かって並行して流れます。

ストリーミング・サーバー・デプロイメントでは、以下の TADDM サーバー・プロパティーを次の値に設定する必要があります。

v com.collation.taddm.mode=DiscoveryServer

v com.collation.taddm.mode=StorageServer

1 次ストレージ・サーバーを除くすべてのサーバーでは、以下のプロパティーも (1 次ストレージ・サーバーのホスト名とポート番号について) 設定する必要があります。

v com.collation.PrimaryStorageServer.host

v com.collation.PrimaryStorageServer.port

com.collation.taddm.mode プロパティーを設定した場合は、com.collation.cmdbmode を設定してはなりません。あるいは、コメント化しなければなりません。

同期サーバー専用のデータベースを持ち、エンタープライズ内のすべてのドメイン・サーバーからのディスカバリー・データを同期する TADDM サーバー。このサーバーはデータを直接にはディスカバーしません。

同期サーバー・デプロイメント同期サーバーが 1 台で、それぞれがローカル・データベースを持つドメイン・サーバーが 2 台以上デプロイされている TADDM デプロイメント。

この情報について xi

このタイプのデプロイメントでは、同期サーバーは、複数のドメイン・サーバーのディスカバリー・データを、バッチの同期プロセスで 1 つのドメインごとにコピーします。

同期サーバー・デプロイメントでは、以下の TADDM サーバー・プロパティーを次の値に設定する必要があります。

com.collation.cmdbmode=enterprise

このタイプのデプロイメントは、廃止になりました。したがって、複数のサーバーを必要とする新規の TADDM デプロイメントでは、ストリーミング・サーバー・デプロイメントを使用してください。同期サーバーは、変換してストリーミング・サーバー・デプロイメントの 1 次ストレージ・サーバーにすることができます。

TADDM データベースTADDM において、構成データ、依存関係、変更履歴が保管されるデータベース。

ディスカバリー・サーバーおよび 2 次ストレージ・サーバー以外の各TADDM サーバーは、専用のデータベースを持ちます。ディスカバリー・サーバーには、データベースがありません。ストレージ・サーバーは、1次ストレージ・サーバーのデータベースを共有します。

TADDM サーバー以下の用語のいずれを指す場合にも使用する一般用語です。

v ドメイン・サーバー・デプロイメントでのドメイン・サーバー

v 同期サーバー・デプロイメントでの同期サーバー

v ストリーミング・サーバー・デプロイメントでのディスカバリー・サーバー

v ストリーミング・サーバー・デプロイメントでのストレージ・サーバー(1 次ストレージ・サーバーを含む)

ターゲット・システムTADDM ディスカバリー処理でディスカバー対象となるシステム。

使用率ディスカバリーホスト・システムの使用率情報をディスカバーする TADDM センサー・スキャン。使用率ディスカバリーでは、オペレーティング・システム資格情報が必要となります。

xii Application Dependency Discovery Manager: 管理

管理

TADDM の概要IBM Tivoli Application Dependency Discovery Manager (TADDM) は、IT 運用要員がアプリケーション環境におけるアプリケーションの可用性を確認して改善するために役立つ、構成管理ツールです。 TADDM は、資産およびそのアプリケーション依存関係を対象とする、自動化されたエージェントレスのディスカバリーを使用して、構成アイテム (CI) の詳細を提供します。また、TADDM には、他のソースからのデータの活用を支援するディスカバリー・ライブラリー・テクノロジーが組み込まれています。

TADDM により、運用スタッフはアプリケーションのトップダウン・ビューを確認し、そのビジネス上重要なアプリケーションの構造、状況、構成、および変更履歴を簡単に把握することができます。パフォーマンスおよび可用性の問題が発生した場合、スタッフはこのビューを利用して即座に問題を切り分け、アプリケーションの変更を混乱なくより効果的に計画することができます。構成管理データベースである TADDM データベースは、インフラストラクチャーのカスタムのモデル化を必要とすることなく、作成され、保守されます。また TADDM は、完全な層間依存マップ、トポロジー・ビュー、変更トラッキング、イベント伝搬、詳細レポート、および詳細なレポートと分析も提供します。

TADDM は、TADDM 製品の一部としてデプロイされるセンサーを使用して実行される情報のディスカバリーに依存します。ディスカバリー・プロセスで生成されるデータを使用して、物理トポロジーと論理トポロジーを関連付ける層間依存マップが作成されます。この階層ディレクトリーは、実行時環境全体を表します。

以下のステップは、TADDM の動作内容の概略を要約したものです。

1. センサーは、各アプリケーション、システム、およびネットワーク・コンポーネントの ID、属性、および設定を判別して収集します。

2. 構成データ、依存関係、および変更履歴は TADDM データベースに保管され、トポロジーは TADDM サーバー上に保管されます。CI がディスカバーされると、以下のソースから TADDM データベースにそれらの CI が保管されます。

v センサー

v 外部の管理ソフトウェア・システムにより生成されるディスカバリー・ライブラリー・ブック (Identity Markup Language (IdML) ブックとも呼ばれる)

v API

3. ディスカバーされたデータは、TADDM ユーザー・インターフェースで、実行時の層間アプリケーション・トポロジーとして表示されます。その後のディスカバリーにより、トポロジーが更新されます。また、TADDM では、インフラストラクチャー構成および依存関係の変更履歴が維持されます。

4. TADDM は、TADDM データベースに保管されている情報のレポートおよび追加のトポロジー・ビューを生成します。

© Copyright IBM Corp. 2006, 2018 1

TADDM がディスカバーするエンティティー

表 1 で、TADDM が環境内でディスカバーするエンティティーをリストして説明します。

表 1. ディスカバーされるエンティティーとその説明

エンティティー説明

ネットワーク層以下のデバイスは、各デバイスの MIB2 (RFC 1213) パラメーター値でディスカバーされます。

v ルーター

v スイッチ

v ロード・バランサー

v ファイアウォール

v 一般 IP デバイス

システム層以下のデバイスは、システム層でディスカバーされます。

v サーバー・ホストおよびディスク

v ホスト IP インターフェース

v データベース・サーバー

v ロード・バランサーまたはクラスター

アプリケーション層以下のコンポーネントは、アプリケーション層でディスカバーされます。また、各コンポーネント (一般プロセスを除く) のバージョン情報、構成ファイルとプロパティー、ホスト情報、およびベンダー固有の拡張機能がディスカバーされます。

v カスタム・サーバー (設計したカスタム・テンプレートに基づく)

v Java EE アプリケーション・サーバーおよび構成

v Java EE および Java SE のコンポーネントおよびモジュール

v Web サーバー・コンポーネント

v Web モジュール、構成ファイル、およびインストール・ディレクトリー

v 汎用 JVM プロセス

v データベース

インフラストラクチャー・サービス

アプリケーション環境をサポートするシステム・インフラストラクチャー・サービスがディスカバーされ、これらのサービス・コンポーネントとアプリケーション・コンポーネント間の依存関係構造がディスカバーされます。インフラストラクチャー・サービス内のコンポーネントは以下のとおりです。

v DNS および NFS の各サービス

v LDAP

2 Application Dependency Discovery Manager: 管理

表 1. ディスカバーされるエンティティーとその説明 (続き)

エンティティー説明

関係構造コンポーネントのディスカバリーに加えて、ネットワーク、システム、およびアプリケーションの各層の物理的および論理的な接続がディスカバーされます。各層は、以下のレベルでサポートされます。

v 第 3 層の IP 接続

v 第 2 層の接続

v アプリケーション・コンポーネントのランタイム依存関係

v インフラストラクチャー・サービスの依存関係

以下のエンティティーにわたって、構成および相互依存関係がディスカバーされます。

v Web サーバー、アプリケーション・サーバー、およびデータベースなどのアプリケーション・コンポーネント

v ホスト、オペレーティング・システム、ロード・バランサー、およびデータベース・サーバーなどのシステム・コンポーネント

v ルーター、スイッチ、およびファイアウォールなどのネットワーク・コンポーネント

v DNS および LDAP サービスなどのインフラストラクチャー・サービス

注: 仮想 IP アドレスまたは複数のネットワーク・インターフェース・コントローラーを使用すると、TADDM が誤った結果を報告する可能性があります。ディスカバリーを計画する際は、ネットワーク・インフラストラクチャーを考慮に入れてください。

ディスカバリー・プロセスの概要ディスカバリーは、ランタイム環境で使用されるデプロイ済みソフトウェア・コンポーネント、物理サーバー、ネットワーク・デバイス、仮想システム、およびホスト・データを識別するアプリケーション・インフラストラクチャー全体に関する構成情報を収集するマルチレベル・プロセスです。ディスカバリーは、TADDM 製品の一部であるセンサーを使用して実行されます。

センサーの役割は、構成アイテム (CI) のディスカバー、モデル・オブジェクトの作成、および TADDM データベースへのモデル・オブジェクトの持続化です。センサーは、ディスカバーするように設計されているリソースに固有のプロトコルを使用します。プロトコルの例は、以下のとおりです。

v Cisco Discovery Protocol (CDP)

v Java™ Management Extensions (JMX)

v Secure Shell (SSH)

v Simple Network Management Protocol (SNMP)

v 構造化照会言語 (SQL)

可能な場合、TADDM サーバーとターゲット・システムとの間ではセキュア接続が使用されます。

管理 3

TADDM は、IPv6 ネットワークでのディスカバリーを実行しませんが、 IPv6 属性は、IPv4 ネットワーク上で実行されるディスカバリーによってディスカバーされます。

センサーTADDM には、アプリケーション・ソフトウェア、ホスト、およびネットワークの各層にわたって、標準的なデータ・センターに存在するほとんどすべてのコンポーネントをディスカバーするための、さまざまな特殊センサーが用意されています。固有なコンポーネント用のカスタム・センサーを作成することもできます。センサーは TADDM サーバーに常駐し、構成属性および依存関係を収集します。

センサーは非侵入的です。つまり、クライアント・ワークステーション上ではなく、TADDM サーバー上で稼働します。したがって、TADDM を使用することで、ディスカバー対象の各クライアント・ワークステーションでエージェントをローカルにインストールして保守するコストを発生させることなく、ディスカバリー関連情報を収集できます。

センサーは、セキュア・ネットワーク接続、暗号化アクセス資格情報、およびホスト固有のユーティリティーを使用するため、セキュアであり、クライアント・ワークステーションにあるソフトウェアを使用する場合と同じレベルのデータ収集を実現します。

センサーには、以下に示す 3 つの構成可能な側面があります。

スコープディスカバリー・スコープは、一般には有効な IP 範囲、サブネット、または特定アドレスです。スコープはディスカバリーの境界を設定します。

アクセス・リストアクセス・リストは、センサーがアプリケーション・インフラストラクチャー内の構成アイテムにアクセスする際に使用する資格情報 (ユーザー名、パスワード、Simple Network Management Protocol (SNMP) コミュニティー・ストリングなど) の集合です。ディスカバーする構成アイテム用にアクセス・リストを構成する必要があります。

スケジュールディスカバリーは、オンデマンドで実行するか、スケジュールに沿って実行するか、または外部でトリガーされたイベントによって駆動することができます。スケジュールは、センサーがオンデマンドで実行されるのか、スケジュールに沿って実行されるのかを区別します。

センサーが構成アイテムをディスカバーする仕組み:

以下のステップでは、センサーが環境内の構成アイテム (CI) をどのようにディスカバーするかを概説します。

1. 指定されたスコープ内のアクティブな IP デバイスを識別するために、センサーはいくつかのポート (22、23、135 など) 上の TCP 接続で応答の検出を試みます。何らかの応答があればセンサーはデバイスが存在していることを報告します。

2. センサーは、いくつかのポート (22 や 135 など) 上で IP デバイスへの接続を試みて、ホストのディスカバーに使用するテクノロジーを決定します。


3. セキュア・シェル (SSH) プロトコルを使用してポートがオープンしている場合、センサーはアクセス・リストの資格情報を使用して SSH 接続の確立を試行します。センサーは、アクセス・リストのタイプ computer system またはwindows computer system のエントリーを順に試します。この操作は、機能するエントリーが検出されるか、または検出できないままセンサーがアクセス・リストの終わりに到達するまで行われます。

4. Windows Management Instrumentation (WMI) ポートがオープンしている場合は、ゲートウェイ・コンピューター・システムとの SSH 接続が確立されます(ターゲット・システムとしてゲートウェイ・コンピューター・システムが検出される場合)。センサーは、アクセス・リストのタイプ windows computersystem のエントリーを順に試します。この操作は、機能するエントリーが検出されるか、または検出できないままセンサーがアクセス・リストの終わりに到達するまで行われます。

5. セッションを確立できない場合は、SNMP センサーが実行されます。セッションが確立された場合は、コンピューター・システム・センサーが実行されます。

6. コンピューター・システム・センサーは、インストールされているオペレーティング・システムのタイプの判別を試みます。

7. TADDM は、オペレーティング・システム固有のセンサーを実行して、オペレーティング・システムをさらに詳しくディスカバーします。

8. 特定の基準 (ポート番号やプロセス名など) に基づいたオペレーティング・システムの詳細なディスカバリーの際に、TADDM はソフトウェア固有のセンサーを実行して、アプリケーションの詳細をディスカバーします。

アプリケーション・センサーが開始される仕組み:

ここでは、アプリケーション・センサーがどのように開始されるかを説明します。

GenericServerSensor は以下のコマンドを実行します。

Linux、Solaris、AIX、および Linux on System z® オペレーティング・システムの場合

v ポート情報を取得するための lsof -nP -i

v コマンド行情報を取得するための ps axww

Windows オペレーティング・システムの場合

v ポート情報を取得するための netstat.exe -nao

v コマンド行情報を取得するための wmic process list

プロセス ID (PID) を使用して出力がマージされます。テンプレート突き合わせ機能は、マージされたデータで動作します。collation.properties ファイルでロギング・レベルが DEBUG に設定されている場合は、これらのコマンドの出力が以下のログに記録されます。

v GenericServerSensor.log

v DiscoverManager.log

マージされたデータは、センサー・テンプレートに定義されている基準と一致している必要があります。センサーを開始するテンプレート基準は、以下に示す DB2®

センサー用のサンプル・テンプレート定義にあります。

管理 5

以下のコマンドを実行します (ファイルへのリダイレクトが役立ちます)。このときに、<username> および <password> を、有効なユーザー名および関連付けられたパスワードに置き換えてください (例えば、...dist/sdk/bin/api.sh -u

administrator -p collation find --depth=5 AppServerTemplate)。

...dist/sdk/bin/api.sh -u <username> -p <password> find --depth=5 AppServerTemplate

上記のコマンドによって、テンプレート定義である XML 出力が生成されます。このテンプレート定義で、<order> エレメントの値が 0 未満であれば、テンプレートはセンサー用です。 <order> エレメントの値が 0 より大きければ、テンプレートはカスタム・サーバー用です。突き合わせは <order> エレメントの最も低い値から行われるため、突き合わせの優先順位はセンサーの方がカスタム・サーバーより高くなります。

以下のサンプル・テンプレート定義は、DB2 センサー用です。 2 つの <operand1>エレメントに注目してください。1 つは値が db2tcpcm、もう 1 つは値が db2agentになっています。 <boolExp> エレメントの値は、<operand1> 値の両方またはどちらか 1 つのみが存在していなければならないことを示します。 <boolExp> エレメントの値 1 は、論理演算子 OR を表し、<operand1> 値のどちらか 1 つのみが存在していなければならないことを意味します。 <boolExp> エレメントの値 0 は、論理演算子 AND を表し、<operand1> 値の両方が存在していなければならないことを意味します。

<Template array="18" guid="C1A992327AFF33409C41D5C71046DBB9"lastModified="1177555771479"xsi:type="coll:com.collation.platform.model.discovery.template.AppServerTemplate">

<displayName>DB2</displayName><name>DB2</name><type>DatabaseServer</type><internal>true</internal><filterSet guid="B599AED918F436C99FDA0E8EDA578F02"lastModified="1177555771475"parent="C1A992327AFF33409C41D5C71046DBB9"xsi:type="coll:com.collation.platform.model.discovery.template.FilterSet">

<displayName>DB2</displayName><filterList array="1"guid="BBE4D351653B37E38BFFD2DEBD532EE8"lastModified="1177555771476"parent="B599AED918F436C99FDA0E8EDA578F02"xsi:type="coll:com.collation.platform.model.discovery.template.Filter">

<displayName>unknown</displayName><operand1>db2tcpcm</operand1><operator>contains</operator><part>Program Name</part>

</filterList><filterList array="2"guid="63816C902B0A317F8C3B24C7A1EEBC17"lastModified="1177555771471"parent="B599AED918F436C99FDA0E8EDA578F02"xsi:type="coll:com.collation.platform.model.discovery.template.Filter">

<displayName>unknown</displayName><operand1>db2agent</operand1><operator>contains</operator><part>Program Name</part>

</filterList><boolExp>1</boolExp>

</filterSet><index>0</index><order>-10</order><enabled>true</enabled>


<action>1</action><source>0</source><seedClass>com.collation.discover.seed.app.db.db2.Db2Seed</seedClass>

</Template>

ディスカバリーのレベルTADDM には 4 つのレベルのディスカバリーがあります。レベル 1 ディスカバリー、レベル 2 ディスカバリー、レベル 3 ディスカバリー、および使用率ディスカバリーです。

レベル 1 ディスカバリーランタイム環境におけるアクティブ・コンピューター・システムに関する基本情報をディスカバーする TADDM センサー・スキャン。このスキャンは、資格情報を必要としないことから、資格情報なしのディスカバリーとも呼ばれます。このスキャンでは、スタック・スキャン・センサーおよびIBM Tivoli Monitoring スコープ・センサーが使用されます。

レベル 1 ディスカバリーは非常に簡単なものです。ディスカバーした各インターフェースのホスト名、オペレーティング・システム名、IP アドレス、完全修飾ドメイン名、およびメディア・アクセス制御 (MAC) アドレスのみが収集されます。また、MAC アドレスのディスカバリーは、Linuxon System z および Windows システムに限定されます。

レベル 1 ディスカバリーは、サブネットをディスカバーしません。ディスカバーした IP インターフェースのうち、レベル 2 またはレベル 3 ディスカバリー中にディスカバーした既存のサブネットに属さないものがあれば、collation.properties ファイル内のcom.collation.IpNetworkAssignmentAgent.defaultNetmask プロパティーの値に基づいて新規サブネットが作成されます。

レベル 2 ディスカバリーランタイム環境における各オペレーティング・システムに関する詳細情報をディスカバーする TADDM センサー・スキャン。このスキャンは、資格情報付きのディスカバリーとも呼ばれ、オペレーティング・システムの資格情報を必要とします。

レベル 2 ディスカバリーでは、実行中の各アプリケーションに関連するアプリケーション名、オペレーティング・システム名、およびポート番号が収集されます。アプリケーションが別のアプリケーションに TCP/IP 接続を確立した場合、この情報は依存関係として収集されます。

レベル 3 ディスカバリーランタイム環境で使用されるアプリケーション・インフラストラクチャー、デプロイ済みのソフトウェア・コンポーネント、物理サーバー、ネットワーク・デバイス、仮想システム、ホスト・データに関する詳細情報をディスカバーする TADDM センサー・スキャン。このスキャンは資格情報付きのディスカバリーとも呼ばれ、オペレーティング・システムの資格情報とアプリケーションの資格情報の両方を必要とします。

使用率ディスカバリーホスト・システムの使用率情報をディスカバーする TADDM センサー・スキャン。使用率ディスカバリーでは、オペレーティング・システム資格情報が必要となります。

管理 7

レベル 2 およびレベル 3 のディスカバリーは、レベル 1 ディスカバリーよりも詳細な情報を収集します。レベル 2 またはレベル 3 のディスカバリーで作成されたオブジェクトが、それまでにレベル 1 ディスカバリーで作成されたオブジェクトと一致する場合は、レベル 1 ディスカバリーで作成されたオブジェクトが新しく作成されたオブジェクトで置き換えられ、それによってオブジェクトのグローバル固有ID (GUID) が変更されます。そのため、通常は、他の製品との統合にレベル 1 データを使用しないでください。

ディスカバリー・プロファイルディスカバリーを実行するには、ディスカバリー・プロファイルを指定する必要があります。ディスカバリー・プロファイルはディスカバリーの一連のオプションを定義します。ディスカバリー・プロファイルを使用して、個別のセンサーの構成、同一センサーの複数構成の管理、一連の条件に基づく適切な構成の選択、および 1回のディスカバリー実行で適用する異なるセンサーの一連の構成の管理などを行うことができます。

適切なディスカバリー・プロファイルを選択することで、ディスカバリーの深さ、つまりディスカバリー・レベルを制御できます。

TADDM には、デフォルトで 4 つのディスカバリー・プロファイルが用意されています。そのうち 3 つは、資格情報なしのディスカバリーと資格情報付きのディスカバリーのどちらが必要であるかに応じて選択できる 3 つのレベルのディスカバリー (レベル 1、レベル 2、レベル 3) 用のプロファイルです。残りのプロファイルは、使用率ディスカバリー用です。

プロファイルを指定しない場合は、デフォルトでレベル 3 ディスカバリー・プロファイルが使用されますが、このデフォルト・プロファイルはディスカバリー管理コンソールで変更できます。

ディスカバリー・プロファイルの追加情報については、TADDM Wiki(https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/A%20Flexible%20Approach%20to%20Discovery) で「A Flexible Approach toDiscovery」を参照してください。

センサーの有効化および無効化

センサーがプロファイルによって有効になっている場合でも、センサーをグローバルに無効にすることができます。また、センサーをグローバルに有効化することや、プロファイル内の設定を機能させることもできます。

例えば、センサーがグローバルに有効化されていて、プロファイルで有効化されている場合、センサーは動作します。センサーがグローバルに有効化されていてもプロファイルで無効化されている場合は、ディスカバリーを実行するためにそのプロファイルを選択してもセンサーは動作しません。

osgi ディレクトリー ($COLLATION_HOME/osgi/plugins) を持つセンサーを機能させるためのグローバルに有効化および無効化するには、osgi ディレクトリーにあるAgentConfigurations を変更する必要があります。

例えば、Db2Sensor の場合は、以下のディレクトリーを探します。


https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/A%20Flexible%20Approach%20to%20Discovery



v $COLLATION_HOME/osgi/plugins/

com.ibm.cdb.discover.sensor.app.db.db2_x.x.x/Db2Sensor.xml

v $COLLATION_HOME/osgi/plugins/

com.ibm.cdb.discover.sensor.app.db.db2windows_x.x.x/Db2WindowsSensor.xml

ここで x.x.x は、センサー・プラグインのバージョンです (例: 7.3)。

XML ファイルを編集するとき、センサーを有効にするには、enabled を true に設定します。センサーを無効にするには、enabled を false に設定します。

osgi/plugins ディレクトリーを使用しないセンサーの場合、構成情報はetc/discover-sensors ディレクトリー内のセンサー構成 XML ファイルに保管されます。

非同期およびスクリプト・ベースのディスカバリー非同期およびスクリプト・ベースのディスカバリーでは、個々のコマンドを実行するのではなく、センサーによって、ターゲット・システムに対して実行するディスカバリー・スクリプトが提供されます。

すべてのセンサーが非同期ディスカバリーとスクリプト・ベースのディスカバリーをサポートしているわけではありません。ディスカバリー・スクリプトを提供するセンサーだけが、これらのタイプのディスカバリーをサポートできます。

非同期およびスクリプト・ベースのディスカバリーをサポートしているセンサーについては、TADDM の「センサー解説書」のトピック『スクリプト・ベースのディスカバリーと非同期ディスカバリーをサポートするセンサー』を参照してください。

非スクリプト・ベースのディスカバリーとの違い

非同期ディスカバリーおよびスクリプト・ベースのディスカバリーと非スクリプト・ベースのディスカバリーとの間には、以下に示す重要な違いがあります。

v 非スクリプト・ベースのレベル 2 またはレベル 3 のディスカバリーでのディスカバリー結果と比べて、非同期またはスクリプト・ベースのディスカバリーでのディスカバリー結果は完全でない場合があります。ほとんどのセンサーは、非スクリプト・ベースのディスカバリーにて、非同期またはスクリプト・ベースのディスカバリーよりも多くのモデル・オブジェクト、属性、および関係をディスカバーします。

v 非同期またはスクリプト・ベースのディスカバリーでは、アプリケーション・センサーが特定のターゲット・システムに対して一度しか開始されません。ただし、アプリケーションが複数のポートで listen している場合は、各アプリケーション・インスタンスがディスカバーされます。非スクリプト・ベースのディスカバリーでは、アプリケーション・インスタンスごとにアプリケーション・センサーが開始されます。

非同期ディスカバリー:

非同期ディスカバリーを実行すると、TADDM サーバーが直接アクセスできないシステムをディスカバーできます。対象となるシステムは、セキュアなロケーション

管理 9

にあるシステム (ネットワーク・アクセスできないシステムなど)、セキュア・シェル (SSH) を実行しないシステム、および資格情報を取得できない機密情報を含んだシステムです。

非同期ディスカバリーでは、ユーザーがターゲット・システムでディスカバリー・スクリプトを実行します。ディスカバリー・スクリプトは、メイン・スクリプトと複数のセンサー・スクリプトで構成されます。各センサー・スクリプトは、一般的なディスカバリーでセンサーが実行する機能と同様のディスカバリー機能を提供します。

ディスカバリー・スクリプトの出力は、ディスカバリー結果を含むアーカイブ・ファイルです。このファイルを TADDM サーバーにコピーする必要があります。TADDM ディスカバリー時に、TADDM センサーが (コマンドの実行はせずに) このアーカイブ・ファイルのディスカバリー結果を処理します。

このディスカバリーは、資格情報が必要な一般的なディスカバリーとは別に手動で実行されるため、「非同期」と呼ばれます。

非同期ディスカバリーを実行するには、非同期ディスカバリー・センサーが必要です。詳しくは、TADDM の「センサー解説書」を参照してください。

非同期ディスカバリーを実行するためのセンサーの構成については、 117 ページの『非同期ディスカバリーの構成』を参照してください。

スクリプト・ベースのディスカバリー:

スクリプト・ベースのディスカバリーでは、資格情報が必要な通常のディスカバリーで、ディスカバリー・スクリプトを使用できます。この種類のディスカバリーでは、非同期ディスカバリーと同じセンサー・スクリプトが使用されます。

スクリプト・ベースのディスカバリーでは、センサーが個々のコマンドを実行することはありません。代わりに、センサー・スクリプトが、ターゲット・システムで実行されます。アプリケーション固有の資格情報が必要とされない場合もあります。

例えば、通常のディスカバリーで IBM WebSphere® アプリケーションをディスカバーするには、セキュリティーが有効になっていれば、WebSphere アプリケーションの資格情報を含むアクセス・リスト・エントリーを作成する必要があります。ただし、スクリプト・ベースのディスカバリーを使用する場合は、WebSphere アクセス・リスト・エントリーは必要ありません。また、スクリプト・ベースのディスカバリーでは、Java Management Extensions (JMX) のようなアプリケーション固有のプロトコルを使用する必要もないため、IBM Tivoli Monitoring を通じたアプリケーション・ディスカバリーを拡張できます。

スクリプト・ベースのディスカバリーを実行するためのセンサーの構成については、 122 ページの『スクリプト・ベースのディスカバリーの構成』を参照してください。

同時実行ディスカバリー複数のディスカバリーを同時に実行できます。これは、同時実行ディスカバリーと呼ばれます。例えば、大規模なディスカバリーは完了までに数時間を要する場合が


あるため、大規模なディスカバリーが完了する前に複数の小規模なディスカバリーの実行を開始すると有効です。同時実行ディスカバリーを実行するには、事前にそれらのディスカバリーを実行する前に、それらを正しく構成する必要があります。

同時実行ディスカバリーは、最初のディスカバリーを開始するために使用したものとは異なるディスカバリー・プロファイルを使用して実行することができます。

同時実行ディスカバリーを管理するには、ディスカバリー管理コンソールまたはapi.sh スクリプトを使用します。api.sh スクリプトの使用方法について詳しくは、TADDM の「SDK 開発者ガイド」の『コマンド行インターフェース API』トピックを参照してください。

同じターゲット・システムに対して同時実行ディスカバリーを実行することができます。いくつかの同じ IP アドレスを 2 つ以上のディスカバリーがモニターしている場合は、それぞれのディスカバリーが個別に動作します。

ディスカバリーの実行中にパスワードの変更が行われた場合に同時実行ディスカバリーが開始されると、その同時実行ディスカバリー内のセンサーは、パスワード変更が行われる前に開始したのでなければ、ただちに新規の資格情報を使用するようになります。

TADDM では、プロファイル・ベースのアクセス・リストを使用する同時実行ディスカバリーはサポートしません。

ディスカバリーの実行中にカスタム・サーバー・テンプレートに変更が加えられた場合、開始されていたすべての同時実行ディスカバリーは、引き続き、既存のバージョンのカスタム・サーバー・テンプレートを使用します。次の独立した非同時実行ディスカバリーのうち開始されているものは、新しいバージョンのカスタム・サーバー・テンプレートを使用します。

表示される FQDN の特定ディスカバーされた各システムの完全修飾ドメイン名 (FQDN) を特定するための優先メソッドを構成することができます。

レベル 1 ディスカバリーの場合は、IP アドレスの逆ルックアップの結果が FQDNです。このルックアップでは、オペレーティング・システムが提供するリゾルバー・ライブラリーが使用され、そこで提供されている構成が使用されます。例えば、オペレーティング・システム・レベルでホスト・ファイルが DNS よりも優先される場合は、ホスト・ファイルの情報が最初に考慮されます。

レベル 2 ディスカバリーの場合は、TADDM が、オペレーティング・システム提供のリゾルバー・ライブラリーを使用して、ディスカバーされたすべての IP アドレスの逆ルックアップを実行します。この場合も、オペレーティング・システム構成で定められている場所から、逆ルックアップが情報を取得します。DNS が構成されていない場合や DNS から不要な FQDN が返された場合は、ホスト・ファイルを使用してその FQDN を指定変更することができます。

ディスカバーされた IP アドレスがルックアップされた後に、FQDN とコンピューター・システムの突き合わせが試行されます。FQDN にはさまざまな取得方法があ

管理 11

り、有効な FQDN が見つかるまで各メソッドがあらかじめ定義された順序で試行されます。この順序を変更して、望ましいメソッドの優先順位を上げることができます。以下のメソッドが使用可能です。

メソッド 1TADDM は、FQDN のホスト部分がディスカバーされたシステムのホスト名と一致する IP インターフェースの FQDN を選択します。複数が一致した場合、選択される FQDN は、プロパティーcom.collation.platform.os.FqdnPriorities に定義されているドメイン名の優先順位によって決まります。このプロパティーには、ドメイン名が優先順位の順にリストされています。ドメインに優先順位を指定するには、次のようにドメイン名をコンマで区切って 1 行に入力します。

com.collation.platform.os.FqdnPriorities=domain1.company.com,domain2.company.com,domain3.company.com

ドメインとして最も高い優先順位が与えられている FQDN が、FQDN として返されます。このメソッドでは、インターフェースおよびコンピューター・システム名の FQDN に関してディスカバーされた情報を使用します。

優先順位が定義されていない場合、TADDM はすべての IP インターフェースを調べます。TADDM は、指定された IP インターフェースと関連付けられた FQDN がコンピューター・システムの名前と一致するかどうか、または、この FQDN のホスト名部分がコンピューター・システムの名前と一致するかどうかをチェックします。基準に最初に一致した FQDN がFQDN として返されます。

例えば、「myname」という名前のコンピューター・システムには以下のFQDN を持つ 2 つのインターフェースがあります。

v interface #1 myname.domain1.com

v interface #2 myname.domain2.com

com.collation.platform.os.FqdnPriorities が定義されていない場合は、最初に一致したものが FQDN 名として返されます。どちらの名前にもディスカバーされたシステムのホスト名に一致する FQDN のホスト部分がありますが、返される FQDN は「myname.domain1.com」です。名前が選択される優先順位を指定するには、プロパティーcom.collation.platform.os.FqdnPriorities を使用します。例えば、com.collation.platform.os.FqdnPriorities エントリーに以下の情報が含まれている場合を考えてみます。

com.collation.platform.os.FqdnPriorities=domain2.com,domain1.com

この場合、返される FQDN は「myname.domain2.com」です。この名前の優先順位のほうが高いからです。

メソッド 2プロパティー com.collation.platform.os.command.fqdn で、逆ルックアップを実行するために使用される TADDM サーバー上の外部コマンドを指定します。以下にこのプロパティーの使用例を示します。プロパティーを 1行に入力します。

com.collation.platform.os.command.fqdn=nslookup $1| grep Name | awk '{print $2}'com.collation.platform.os.command.fqdn.AIX=nslookup $1


| grep Name | awk '{print $2}'com.collation.platform.os.command.fqdn.Linux=nslookup $1| grep Name | awk '{print $2}'com.collation.platform.os.command.fqdn.SunOS=nslookup $1| grep Name | awk '{print $2}'com.collation.platform.os.command.fqdn.Windows=nslookup $1

メソッド 3プロパティー com.collation.platform.os.command.hostOfHostname で、FQDN を提供するために使用されるターゲット・システム上の外部コマンドを指定します。以下に UNIX システムでのこのプロパティーの使用例を示します。プロパティーを 1 行に入力します。

com.collation.platform.os.command.hostOfHostname=host `hostname`| awk {'print $1'}

メソッド 41 次インターフェースの FQDN が使用されます。1 次 IP インターフェースは、IP 値が昇順にソートされている場合、最も低い IP 値として指定されます。

メソッド 51 次インターフェースの IP アドレスが使用されます。

メソッド 6コンピューター・システムの名前が使用されます。

メソッド 7セッション・コンテキスト IP に設定します。

メソッド 8CS に対する FQDNを、セッション IP に対する FQDNとして設定します。

これらのメソッドが試行される順序を定義するには、com.collation.platform.os.fqdnSearchOrder プロパティーを設定します。このプロパティーの値は、コンマで区切られたメソッド番号のリストです。デフォルト値は 1,2,3,4,5,6,7,8 です。この場合、TADDM はまずメソッド 1 を使用します。これで有効な FQDN が返されなかった場合は、有効な FQDN が取得されるまでメソッド 2 以降を順に使用し、取得した時点で停止します。有効な FQDN は、RFC1035 で規定されているルールに適合する完全修飾ドメイン名です。

このソリューションは、SNMP センサーを使用してディスカバーされるコンピューター・システムにも適用されます。どのソリューションに高い優先順位を与えるかを定義し、そのソリューションを使用して FQDN がより迅速に検出されるようにすることができます。

いずれの場合も、正しく構成された DNS がホスト名を設定する方法として優先されます。DNS を使用できない場合は、ホスト・ファイルを使用します。DNS またはホスト・ファイルを使用することは、IP アドレスのネーム解決を実現する標準的な方法です。TADDM では、これらの方法を指定変更する方法を提供していますが、他の方法は TADDM 固有であるため、解決された名前が他の管理システムでの名前と一致しない場合があります。

管理 13

ディスカバリーのトレースディスカバリーが開始されてから変更履歴が更新されてトポロジー依存関係が構築されるまでの間、ディスカバリーの各フェーズをトレースすることができます。ディスカバリーの各フェーズは、関連するログ・ファイルに記録されます。

ディスカバリーの実行フェーズとログ・ファイル

ディスカバリーを開始すると、固有の ID (実行 ID) が各ディスカバリーに割り当てられます。YYYY-MM-DD-hh:mm:ss:SSS という形式のタイム・スタンプ(20110517225225948 など) により、ディスカバリーの実行が識別されます。YYYY-MM-DD の部分は、年、月、日を表します。hh:mm:ss.sss の部分は、24 時間クロックの時刻を 1000 分の 1 秒単位で表します。上記の例の場合、日付は2011/05/17 で、時刻は 22:52:25.948 です。この ID を使用して、$COLLATION_HOME/log/sensors ディレクトリー内のセンサーごとに、別個のログ・ファイルを作成することができます。これらのログ・ファイル内では、このタイム・スタンプが使用されます。

プロセス・フロー・マネージャーは、ディスカバリー中に、ディスカバリーの状態とセンサー・イベントの状態をモニターします。また、プロセス・フロー・マネージャーは、あるサービスから別のサービスへの受け渡しを管理します。プロセス・フロー・アクティビティーは、ディスカバリー・サーバーまたはドメイン・サーバー上の $COLLATION_HOME/log/services/ProcessFlowManager.log ファイルに格納されます。

以下の例は、プロセス・フロー・マネージャーによってモニターされるさまざまなアクティビティーと、この情報がログ・ファイルにどのように格納されるのかを示しています。

ディスカバリーの開始– 2011-05-17 22:53:01,643 ProcessFlowManager [RMI TCP Connection(42)-127.0.0.1] INFOprocessflowmgr.ProcessFlowManagerImpl - [ProcessFlowManagerImpl.I.0] startDiscovery()started discovery with run id 2,011,051,722,525,948– 2011-05-17 22:53:01,643 ProcessFlowManager [RMI TCP Connection(42)-127.0.0.1] INFOprocessflowmgr.ProcessFlowManagerImpl - [ProcessFlowManagerImpl.I.22] startDiscovery()setting the discoveryRun's run id to 2,011,051,722,525,948– 2011-05-17 22:53:01,973 ProcessFlowManager [RMI TCP Connection(42)-127.0.0.1] INFOprocessflowmgr.ProcessFlowManagerImpl -Discovery run, 2011051722525948 started with profile Level 2 Discovery

ディスカバリーの完了– 2011-05-17 22:56:11,689 ProcessFlowManager [RMI TCP Connection(45)-127.0.0.1] INFOprocessflowmgr.ProcessFlowManagerImpl - [ProcessFlowManagerImpl.I.36]discoveryDone(2,011,051,722,525,948) called by Discovery Manager

ディスカバリー・イベント– 2011-05-17 22:53:49,901 ProcessFlowManager [RMI TCP Connection(45)-127.0.0.1] INFOprocessflowmgr.ProcessFlowManagerImpl - [ProcessFlowManagerImpl.I.32]discoveryProgress(2,011,051,722,525,948, Discovered - The CustomAppServerSensor(JavaServer 9.156.47.175:36750) sensor discovered the following: CustomAppServerResult,JavaServer,9.156.47.175:36750.) called by Discovery Manager

トポロジー・ビルダーのフェーズとログ・ファイル

トポロジー・ビルダーは、ディスカバーされたアイテム間の関係と依存関係を構築します。トポロジー・ビルダーは、$COLLATION_HOME/etc/

TopologyBuilderConfigurationDefault.xml ファイルにリストされている一連のエージェントを実行します。トポロジー・エージェントは、指定された間隔で実行さ


れます。ただし、ディスカバリー中とディスカバリーの完了時に発生したイベントによっても、トポロジー・ビルダーが起動されることがあります。各エージェントは、特定のタスク (統合、依存関係の検出、依存関係グラフの作成、古い情報の削除など) を実行します。トポロジー・ビルダーのログ・ファイルは、ドメイン・サーバー、同期サーバー、および 1 次ストレージ・サーバー上の$COLLATION_HOME/log/services/TopologyBuilder.log ファイルと$COLLATION_HOME/log/agents/*.log ファイルに格納されます。

以下の例は、関係を構築する際のさまざまなステージと、この情報がログ・ファイルにどのように格納されるのかを示しています。

ビルダー実行の開始– 2011-05-17 22:56:11,717 TopologyBuilder [RMI TCP Connection(158)-127.0.0.1]INFO cdb.TivoliStdMsgLogger- CTJOT0400I Topology builder is starting.

トポロジー・ビルダーの完了– 2011-05-17 23:16:39,429 TopologyBuilder [[email protected]]INFO engine.TopologyBuilderEngine - Topology agent completed :all normally in seconds 30.367

次のトポロジー・エージェントへの移動– 2011-05-17 23:16:29,774 TopologyBuilder [[email protected]]INFO cdb.TivoliStdMsgLogger - CTJOT0403I Topology builder agent classcom.ibm.cdb.topomgr.topobuilder.agents.ComputerSystemConsolidationAgent is stopping.– 2011-05-17 23:16:30,078 TopologyBuilder [[email protected]]INFO cdb.TivoliStdMsgLogger - CTJOT0402I Topology builder agent classcom.ibm.cdb.topomgr.topobuilder.agents.ComputerSystemTypeAgent is starting.

例えば、トポロジー・ビルダーが停止しているなどの問題が見つかった場合は、最後に開始されたトポロジー・エージェントをログ・ファイルで調べて、問題を特定してください。 TopologyBuilder.log ファイルに項目がない場合、TopologyManager.log ファイルで、最後に開始されたエージェントのタイム・スタンプ以降の項目を調べてください。問題の原因となっているエージェントが判明している場合は、$COLLATION_HOME/log/agents/

agentName.log ファイルを調べてそれらのエージェントを特定することもできます。

その他のサービスとログ・ファイル

変更マネージャーは、イベントを処理して変更履歴レコードを更新します。この処理はディスカバリー・フェーズとは独立して実行され、他のサービス (トポロジー・ビルダー・プロセスや一括ロード・プログラムなど) からイベントを受け取ります。トポロジー・ビューを開くと、GUI で効率的にトポロジーをレンダリングするために必要な構成が、ビュー・マネージャーによって作成されます。サービス・ログは、$COLLATION_HOME/log/services ディレクトリーに格納されます。各サービス・ログの名前は、サービスと同じになります (services/ChangeManager.log ファイルなど)。

以下の例は、この情報がサービス・ログ・ファイルにどのように格納されるのかを示しています。

ChangeManager:2011-05-19 13:22:42,342 ChangeManager [ChgWork-1] INFO changemgr.ChangeManagerPersisterImpl -[ChangeManagerPersister.I.3] Got a create or delete event

管理 15

ViewManager:2011-05-19 16:37:22,428 ViewManager [RMI TCP Connection(174)-127.0.0.1]INFO viewmgr.ViewMetaLoader - [ViewMetaLoader.I.31] getViewMeta()found view meta definition for view Business Application Topology

最後の正常な資格情報キャッシングTADDM は、有効な最後のアクセス資格情報をキャッシュに入れることができます。これらの資格情報は、次の (レベル 2 またはスクリプト・ベースの) ディスカバリーで再利用できます。

ターゲットの初期ディスカバリー中に、TADDM サーバーはアクセス・リストを順に処理し、各項目をディスカバリー・ターゲットに照らして検証します。有効な資格情報が見つかると、キャッシュに入れられ、同じディスカバリー・ターゲットの連続ディスカバリー中に再利用されます。

キャッシュには、以下の 2 つの値を入れることができます。

資格情報この値は、ディスカバリー中にディスカバリー・ターゲットの有効な資格情報が見つかった場合にキャッシュに入れられます。次のディスカバリー中に、これらの資格情報がキャッシュから読み取られ、依然として有効であるかどうか検査されます。依然として有効な場合は、ディスカバリーのために使用されます。有効でなくなっていて、フォールバックが無効になっている場合は、最後の試行が失敗したという情報がサーバーに格納され、ディスカバリーは停止します。フォールバックが有効になっている場合、サーバーはアクセス・リストを順に処理し、新しい有効な資格情報を見つけようとします。フォールバックを有効にするには、com.ibm.cdb.security.auth.cache.fallback.failed プロパティーを trueに設定します。

最後の試行が失敗したという情報 (最後のエラーと共に)この値は、ディスカバリー中にディスカバリー・ターゲットの有効な資格情報が見つからない場合にキャッシュに入れられます。フォールバックが無効になっている場合は、最後の試行が失敗したという情報が表示され、ディスカバリーは停止します。フォールバックが有効になっている場合、サーバーはアクセス・リストを順に処理し、新しい有効な資格情報を見つけようとします。フォールバックを有効にするには、com.ibm.cdb.security.auth.cache.fallback.invalid プロパティーを trueに設定します。

デフォルトでは、両方の場合でフォールバックは有効になっています。アクセス資格情報のキャッシング・プロパティーを適切に設定することによって、フォールバックの動作と資格情報のキャッシングをカスタマイズできます。

注: 資格情報は、接続時に使用される IP アドレス、ロケーション・タグ、資格情報タイプ、およびプロトコルごとにキャッシュに入れられます。アクセス・エントリーが除去されると、すべての関連付けられているキャッシュ項目も除去されます。資格情報キャッシュは、新しいユーティリティー cachemgr によって管理できます。


制限

v レベル 3 ディスカバリーでは、資格情報キャッシュが使用されません。これが使用されるのは、レベル 2 コンピューター・システム・ディスカバリーとスクリプト・ベースのセンサーのみです。

v キャッシュは、スコープ・アクセス制限の変更を追跡しません。例えば、ディスカバリー・ターゲットがスコープ・アクセス制限内にあり、ディスカバーされてキャッシュに入れられた後で、スコープ付き制限から移動された場合は、引き続きキャッシュに入っている値が使用されます。

v キャッシュに入っている値が、プロファイルされたアクセス・リストに優先します。例えば、メイン・アクセス・リストを使用してディスカバリーを実行し、有効な資格情報が格納された場合は、プロファイルに他の資格情報を指定した場合でも、引き続きキャッシュに入っている値が使用されます。

キャッシュに入っている値は、cachemgr ユーティリティーを使用して除去できます。同じディスカバリー・ターゲットまたはスコープに対して、アクセス・エントリーが異なるさまざまなプロファイルを頻繁に使用する場合は、キャッシュを無効にすることができます。そうしないと、間違った資格情報がディスカバリーで使用される可能性があります。

トポロジー構築プロセスの概要TADDM は、トポロジー構築プロセスを定期的に実行します。ディスカバリー後またはバルク・ロード操作後にトポロジー構築プロセスが実行されるまでは、TADDM データベースに未調整のオブジェクトが存在していたり、トポロジー関係が不完全であったりする可能性があります。

このプロセスは、使用する TADDM デプロイメントのタイプに関係なく同じです。

トポロジー構築では、以下の操作が行われます。

TADDM データベースのクリーンアップこのプロセスでは、古いエンティティーが削除され、ソースまたはターゲットが欠落している依存関係が除去され、置き換えられるその他の項目が除去されます。

構成アイテム間の依存関係の確立このプロセスでは、通信するプロセス間 (アプリケーションと基礎となるデータベースの間、WebSphere MQ の送信キューと受信キューの間など) に依存関係が作成されます。また、アプリケーション・クラスターの各部分間の依存関係や、2 つのコンピューター・システム間の依存関係も確立されます。

構成アイテムの作成と拡大このプロセスでは、既存の構成アイテムおよび接続の情報を使用して、新しい構成アイテムが合成されます。例えば、TADDM では、以前のディスカバリーおよびバルク・ロード操作から導出された情報を基に「ApplicationServerClusters」と呼ばれる新しい構成アイテムが作成される場合があります。

管理 17

トポロジー・ビュー用の情報の作成このプロセスでは、データ管理ポータルでトポロジー・ビューをより迅速に表示するために使用できる情報が生成され、保管されます。

データのエクスポートこのプロセスでは、TADDM データベースを照会して、構成アイテムの情報を外部システムにエクスポートします。例えば、レジストリー・サービスとの統合はトポロジー・エージェントとして実装されます。

ログ・ファイルおよびロギングTADDM のログ・ファイルの説明、およびトラブルシューティング用にロギングをセットアップする方法については、TADDM の「トラブルシューティング・ガイド」とそのトピックを参照してください。

環境の保護セキュア環境では TADDM は、機密情報の保護のために認証を強制します。

ユーザー・アカウントは、データ管理ポータルを使用して構成できます。各ユーザーは、データ管理ポータルを使用してネットワークおよびインフラストラクチャーのコンポーネントに関するディスカバーされた情報にアクセスするために、有効なユーザー・アカウントを所有する必要があります。

ディスカバリー管理コンソールにログインして、「セキュア (SSL) セッションを確立する」オプションを選択すると、ネットワークでデータを送信する前に、(ユーザー名およびパスワードを含めて) すべてのデータが暗号化されます。

ディスカバリー・プロセスでは、TADDM サーバーはセキュア・シェル (SSH) プロトコルを使用し、SSH をサポートするすべてのコンピューター・ホストおよびその他のデバイスとの間で、セキュアな通信を行います。

このサーバーは、鍵ベースの SSH 認証、およびログイン・ベースとパスワード・ベースの SSH 認証の両方をサポートしています。ログイン・ベースでパスワード・ベースの SSH 認証が使用されている場合、ディスカバーされるコンピューター・ホストへのログインには、アクセス・リストで定義されているユーザー名とパスワードが使用されます。

104 ページの『セキュリティー・プロパティー』も参照してください。

構成アイテムへのユーザー・アクセスのコントロールTADDM は、アクセス・コレクション、役割、および許可を使用して、構成アイテムへのユーザー・アクセスをコントロールします。

構成アイテムに対するアクセス・コントロールは、以下のプロセスで確立されます。

1. 構成アイテムがアクセス・コレクションに集約されます。

2. 許可のセットを集約する役割が定義されます。


3. ユーザーまたはユーザー・グループが定義され、役割が各ユーザーまたはユーザー・グループに割り当てられて、(特定のアクセス・コレクションのための) 特定の許可がそのユーザーに付与されます。

TADDM におけるセキュリティーのコンテキストでは、ユーザーとは構成アイテムに対するアクセス権限を与えられている個人であり、ユーザー・グループとは同じ役割または許可を持つ複数のユーザーです。

ユーザーおよびユーザー・グループは、データ管理ポータルで作成できます。構成アイテムに対するユーザーおよびユーザー・グループのアクセス権限は、各ユーザーまたはユーザー・グループに割り当てた役割およびアクセス・コレクションによって定義されます。これらの割り当てはいつでも変更できます。

許可許可とは、アクションを実行したり、特定の構成アイテムにアクセスしたりする権限をユーザーに与えるものです。許可は役割に集約され、それらの許可を持つ役割をユーザーに割り当てることにより、そのユーザーは許可を付与されます。

TADDM は 4 つの許可を付与します。それぞれの許可は、データ・レベルの許可とメソッド・レベルの許可に分類されます。

データ・レベルの許可

読み取りおよび更新は、データ・レベルの許可です。

読み取りユーザーは、構成アイテムに関する情報を表示できます。

更新ユーザーは、構成アイテムに関する情報を変更できます。

メソッド・レベルの許可

ディスカバーおよび管理は、メソッド・レベルの許可です。

ディスカバーユーザーは、例えばディスカバリー管理コンソールの「編集」メニューから、ディスカバリーの開始、ディスカバリー・スコープ・オブジェクトの作成および更新、または新規オブジェクトの作成を行うことができます。

ディスカバー許可を持っていないユーザーは、ディスカバリー管理コンソールにログインしたり、データ管理ポータルで「ディスカバリー」タブを表示したりすることはできません。

管理ユーザーは、ユーザー、役割、および許可を作成または更新できます。また、許可マネージャーで許可ポリシーを構成できます。

データ・レベル・セキュリティーの使用可能化

collation.properties ファイルを編集することにより、AIX、Linux、Linux onSystem z、および Windows オペレーティング・システムのデータ・レベル・セキュリティーを有効にできます。

データ・レベル・セキュリティーを使用可能にして、読み取り許可と更新許可を選択的に付与できるようにするには、以下のステップを実行します。

管理 19

1. collation.properties ファイルで以下の行を見付け、プロパティーの値をfalse から true に変更します。

com.collation.security.enabledatalevelsecurity=false

2. ファイルを保管します。

3. TADDM サーバーを停止します。

4. TADDM サーバーを再始動してください。

注: ストリーミング・サーバー・デプロイメントでは、各ストレージ・サーバーのcollation.properties ファイルを更新して、各ストレージ・サーバーを再始動する必要があります。

アクセス・コレクションを作成すると、さらに細かくアクセス権限を設定できます。データ・レベル・セキュリティーが使用可能である場合、アクセス・コレクションを使用して、主要な TADDM リソースを保護することができます。データ・レベル・セキュリティーが有効な場合、ユーザーは、アクセス・コレクションに含まれる CI のうち、自分が更新許可を持っている CI のみ変更することができます。

SiteInfo 属性を含む物理的地理リソースなどの補助リソースは、アクセス・コレクションの作成時に表示されません。

役割役割とはユーザーに割り当てることができる許可のセットです。役割を割り当てると、特定のアクセス機能が与えられます。

役割をユーザーに割り当てるときに、役割に 1 つ以上のアクセス・コレクションを指定する必要があります。役割のスコープを、そのユーザーに適したアクセス・コレクションにのみ制限できます。

例えば、Sarah は社内の NT サーバーおよびワークステーションを担当しているので、これらのシステムを含むアクセス・コレクションに対するスーパーバイザー役割を Sarah に割り当てます。Jim は Linux システムを担当しているので、これらのシステムを含むアクセス・コレクションに対するスーパーバイザー役割を Jim に割り当てます。Sarah と Jim には (行う操作が同じであるため) 同じ役割が割り当てられていますが、アクセス権限のあるリソースは異なります。

注: 同期サーバーを使用している場合は、TADDM ドメインごとに役割を作成して、これらのドメイン・サーバーを同期サーバーと同期する必要があります。

事前定義ロール

TADDM には、以下の事前定義済み役割が用意されています。

オペレーターこの役割には、読み取り許可が設定されています。

スーパーバイザーこの役割には、読み取り、更新、およびディスカバー許可が設定されています。


管理者この役割には、読み取り、更新、ディスカバー、および管理許可が設定されています。

作成可能な追加役割

その他の許可の組み合わせを割り当てる場合は、追加の役割を作成できます。特に、以下の組み合わせが役に立つことがあります。

読み取り + 更新割り当て済みのアクセス・コレクション内のオブジェクトを読み取り、更新する許可。

読み取り + 更新 + 管理割り当て済みのアクセス・コレクション内のオブジェクトを読み取り、更新し、ユーザー、役割、および許可を作成する許可。

アクセス・コレクションTADDM は、構成アイテムへのアクセスを個別に管理しません。その代わりに、構成アイテムをアクセス・コレクションと呼ばれるセットに集約します。アクセス・コレクションは、セキュリティーの目的で集合的に管理される構成アイテムのセットです。

その後、各アクセス・コレクションのセキュリティーは、役割を作成し、その役割をユーザーに割り当てることによって管理されます。役割は、それをユーザーに割り当てるときに指定するアクセス・コレクションにのみ適用されます。したがって、アクセス・コレクションは、役割の適用範囲を制限するために使用されます。

TADDM をインストールするときに、DefaultAccessCollection という名前のアクセス・コレクションが作成されます。このコレクションには、すべての構成アイテムが含まれます。データ・レベル・セキュリティーを有効にしていない限り、デフォルトでは、すべてのユーザーに、このアクセス・コレクションに対する読み取り許可と更新許可が付与されます。

注: ユーザーは、アクセス・コレクションに対する読み取り許可と更新許可を持っておらず、個々の構成アイテムの読み取りと更新のみを行うことができます。ただし、ユーザーは、自分に割り当てられたアクセス・コレクションのメンバーであるアクセス・コレクションに対する読み取り許可と更新許可は持っています。

セキュリティー・ポリシーのリセットセキュリティー・ポリシー (許可、役割、およびアクセス・コレクション) をリセットしてデフォルト状態に戻す必要がある場合、2 つのファイルを置き換えることによって行うことができます。ただし、セキュリティー・ポリシーをリセットするには、すべてのユーザーを削除して再作成する必要があります。

このタスクについて

セキュリティー・ポリシーは、$COLLATION_HOME/var/policy ディレクトリーにある以下の 2 つのファイルに格納されます。これらのファイルは、セキュリティー・ポリシーを初期化するために使用されます。

v AuthorizationPolicy.xml

管理 21

v AuthorizationRoles.xml

セキュリティー・ポリシーが初期化された後、これらのファイルは名前が変更されて、同じディレクトリーに保管されます。例えば、以下のファイルが、名前が変更されたものです。

v AuthorizationPolicy.backup.xml

v AuthorizationRoles.backup.xml

これらのファイルのデフォルト・バージョン (提供されたセキュリティー・ポリシーを包含している) も、同じディレクトリー内にあります。次に示すファイルはデフォルト・バージョンです。

v DefaultPolicy.xml

v DefaultRoles.xml

手順

デフォルトのセキュリティー・ポリシーを復元するには、以下のステップを実行します。

1. 現行のポリシー・ファイルを保存するには、それらの名前を変更するか、別のディレクトリーに移動します。

2. 作成したすべてのユーザーを削除します。

3. $COLLATION_HOME/var/ibmsecauthz ディレクトリーを削除します。

4. DefaultPolicy.xml ファイルのコピーを作成して、それにAuthorizationPolicy.xml という名前を付けます。

5. DefaultRoles.xml ファイルのコピーを作成して、それにAuthorizationRoles.xml という名前を付けます。

6. サーバーを再始動します。

7. 必要に応じて、ユーザーを作成します。

ロックアウトロックアウトを使用すると、構成済みの許可されるログイン試行失敗回数を超えた場合に、単一ユーザー、または全ユーザーを TADDM からロックアウトすることができます。ロックアウト機能を使用することによって、認証制御が向上し、ブルート・フォース方式のパスワード解読の防止に役立ちます。

単一ユーザーが構成済みのログイン試行失敗回数を超えると、ローカル・ロックアウトがトリガーされます。その結果、構成済みの時間が過ぎるまでは、そのユーザーは TADDM にログインできません。

グローバル・ロックアウトがトリガーされると、構成済みの時間が過ぎるまではどのユーザーも TADDM にログインできません。グローバル・ロックアウトは、以下の 2 つの状態のいずれかによってトリガーされます。

v 異なるユーザーのアクティブなロックアウトの数が、構成済みの許可される最大グローバル・ロックアウト数を超えた場合。

v 固有ユーザー名のログイン試行失敗回数が構成済みの制限を超えた場合。

ロックアウトがトリガーされた場合でも、既存のセッションは影響を受けません。


collation.properties ファイル内のプロパティーを構成することによって、許可されるログイン試行失敗回数と、ロックアウトをアクティブのままにしておく時間を指定することができます。これらのプロパティーについて詳しくは、 100 ページの『ロックアウト・プロパティー』を参照してください。

グローバル・ロックアウト時間が経過すると、進行中のすべてのローカル・ロックアウトは自動的にクリアされます。

同期サーバー・デプロイメントでは、同期サーバーがすべての TADDM ドメインのセキュリティーを制御します。ドメイン・サーバーが同期サーバーに接続する前にドメイン・サーバー上でアクティブであったロックアウトはすべて、ドメイン・サーバーと同期サーバーの間の同期が可能になったときにクリアされます。

合計にカウントするログイン試行失敗は、どのようなタイプのものでも構いません。例えば、 CLI API、Java API、ツール (スクリプト)、SOAP、REST、ディスカバリー管理コンソール、またはデータ管理ポータルなどの使用が含まれます。ロックアウト機能は、TADDM API を使用する統合に適用されますが、シングル・サインオンを使用したログインや、データベース・ベースの統合 (Tivoli CommonReporting など) には適用されません。

TADDM サーバー管理者は、$COLLATION_HOME/bin/lockmgr.sh スクリプトを使用して、ローカル・ロックアウトまたはグローバル・ロックアウトをクリアできます。スクリプトは以下のサーバーから実行できます。

v ドメイン・サーバー・デプロイメントのドメイン・サーバー

v 同期サーバー・デプロイメントの同期サーバー

v ストリーミング・サーバー・デプロイメントの 1 次ストレージ・サーバー

lockmgr.sh スクリプトは以下のオプションを指定して実行できます。

lockmgr.sh -sロックアウト状況を表示します。

lockmgr.sh -gアクティブなグローバル・ロックアウトをクリアします。

lockmgr.sh -u username

特定のユーザーのアクティブなローカル・ロックアウトをクリアします。

lockmgr.sh -hlockmgr.sh スクリプトのヘルプ情報を表示します。

暗号化暗号化は、オリジナル・データを取得できないようにするか、または暗号化解除プロセスを使用することによってのみ取得できるようにする方法で、データを分かりにくい形式に変換するプロセスです。

Fix Pack 5

TADDM では、プロパティー 'com.collation.security.algo.aes.keylength' を

使用して、FIPS 準拠 IBMJCEFIPS セキュリティー・プロバイダーのアルゴリズム(AES 128 または AES 256) を決定し、以下の項目を暗号化します。

v collation.properties および userdata.xml ファイル内のエントリーを含むパスワード

管理 23

v データベースに保管されたアクセス・リスト・エントリー

例:

このプロパティーは、AES の鍵の長さを定義します -com.collation.security.algo.aes.keylength=128。

TADDM を初めてインストールするときに、暗号鍵が生成され、この新しい暗号鍵を使用してパスワードが暗号化されます。暗号鍵のデフォルト・ロケーションはetc/TADDMSec.properties ファイルです。

TADDM 暗号鍵のロケーションの変更

暗号鍵ファイルのロケーションを変更するには、collation.properties ファイルでcom.collation.security.key プロパティーの値を変更します。このプロパティーは、$COLLATION_HOME ディレクトリーに相対的な別のロケーションに設定できます。

データ損失を避けるために、暗号鍵のバックアップ・コピーを別のロケーションに保管してください。この鍵は、オリジナルのコピーに問題が発生した場合にリストアできます。

ドメイン・サーバー・デプロイメントでの TADDM 暗号鍵の変更

注: ストリーミング・サーバー・デプロイメントおよび同期サーバー・デプロイメントの場合、TADDM では、インストール後の暗号鍵の変更はサポートされていません。

ドメイン・サーバー・デプロイメントで TADDM 暗号鍵を変更するには、bin/changekey.sh スクリプト (または同等のバッチ・スクリプト・ファイル) を使用します。このスクリプトは、collation.properties ファイルおよびuserdata.xml ファイル内の暗号化されたエントリーと、データベースに保管されたアクセス・リスト・エントリーをマイグレーションします。bin/changekey.sh スクリプトを使用するには、インストール中に定義された非 root ユーザーとしてログインしていることを確認します。

このスクリプトを正常に使用した後で、TADDM を再始動する必要があります。

スクリプトを実行するための形式./changekey.sh $COLLATION_HOME admin_user admin_password

例./changekey.sh /opt/IBM/taddm/dist administrator taddm

FIPS 準拠FIPSMode プロパティー com.collation.security.FIPSMode を true に設定することにより、FIPS に準拠する暗号化アルゴリズムを使用するモードで作動するようTADDM を構成することができます。

以下のファイルで com.collation.security.FIPSMode プロパティーを true に設定します。

v $COLLATION_HOME/dist/etc/collation.properties


v $COLLATION_HOME/dist/sdk/etc/collation.properties

v FIPS 準拠の TADDM に接続するすべての TADDM SDK インストール済み環境の sdk/etc/collation.properties。

com.collation.security.FIPSMode プロパティーのデフォルト値は false です。

FIPS モードでは、TADDM は以下の FIPS 140-2 承認済み暗号プロバイダーを使用します。

v IBMJCEFIPS (証明書 376)

v IBMJSSEFIPS (証明書 409)

証明書 376 および 409 について詳しくは、米国連邦情報・技術局 (NIST) の Webサイト (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm) を参照してください。

FIPS モードは、以下の例外を除き、すべてのタイプの TADDM ディスカバリーで使用できます。

v レベル 2 SNMP ディスカバリー

v レベル 2 i5/OS ディスカバリー

v レベル 2 ZEnterprise ディスカバリー

v レベル 2 VMware ESXi ディスカバリー

v レベル 3 VMware Virtual Center ディスカバリー

v レベル 3 JBoss ディスカバリー

v レベル 3 Oracle Application Server ディスカバリー

v レベル 3 WebLogic ディスカバリー

v レベル 3 SAP CCMS および SLD ディスカバリー

v レベル 3 EMC ディスカバリー

v Fix Pack 1 レベル 3 Sybase ディスカバリー

v Windows Management Instrumentation (WMI) セッションまたは PowerShellセッション (PowerShell セッションは TADDM 7.3.0.2 以降でサポートされています) を使用して Windows プラットフォームをディスカバーするレベル 2およびレベル 3 のディスカバリー (ただし、Windows TADDM サーバー、Windows ゲートウェイ、および Windows ディスカバリー・ターゲットがFIPS 準拠モードで稼働していない場合に限ります)。 FIPS 準拠モードで稼働するように Windows サーバーを構成するには、Windows の資料を参照してください (http://support.microsoft.com/kb/811833 など)。

FIPS モードの場合、SSH を使用する TADDM センサーは、弱すぎる暗号を使用する SSHv1 プロトコルまたは SSHv2 プロトコルのみをサポートするサーバーには接続できません。 TADDM は、ターゲット・サーバー上の SSH 実装が FIPS に準拠しているかどうかを検証できません。ご使用の環境で使用する SSH 実装が FIPSに準拠しているかどうかは、ご自分で確認する必要があります。

FIPS モードでは、TADDM SDK およびディスカバリー管理コンソールをセキュア・モードで使用する場合は IBM Java のみがサポートされます。

関連概念:

管理 25

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2004.htm

http://support.microsoft.com/kb/811833

『SP800-131 への準拠』米国連邦情報・技術局 (NIST) SP800-131a セキュリティー標準をサポートするように TADDM を構成できます。

SP800-131 への準拠米国連邦情報・技術局 (NIST) SP800-131a セキュリティー標準をサポートするように TADDM を構成できます。

SP800-131a セキュリティー標準では、他の標準 (例えば、FIPS 140-2 標準) よりも長い鍵や、より強力な暗号化が必要です。また、トランスポート層セキュリティー(TLS) v1.2 も必要です。詳しくは、http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf を参照してください。

SP800-131a モードを有効にするには、以下のファイルで com.ibm.jsse2.sp800-131プロパティーに strict を設定します。



v SP800-131 準拠の TADDM に接続するすべての TADDM SDK インストール済み環境の sdk/etc/collation.properties。

デフォルトでは、com.ibm.jsse2.sp800-131 プロパティーは設定されていません。

SP800-131a 準拠モードは、FIPS モードの場合のように、同じタイプの TADDMディスカバリーでサポートされます。

SP800-131 モードの場合、TADDM は、暗号化通信の際、最も安全な SSL プロトコル (TLS v1.2) を使用します。以下の要件が満たされていることを確認します。

v Web SSL ポート (HTTPS) 経由でデータ管理ポータルを使用するときは、最初に、TLS v1.2 プロトコルをサポートするように Web ブラウザーを構成する必要があります。

v TADDM SDK およびディスカバリー管理コンソールをセキュア・モードで使用するときは、Java ランタイム環境で TLS v1.2 プロトコルを有効にする必要があります。また、サポートされるのは IBM Java のみです。

v SSL 証明書が SP800-131a 標準に準拠していない場合は、この証明書を再作成する必要があります。必要な手順については、 38 ページの『TADDM での使用を目的としたカスタマイズした SSL 証明書のインストール』を参照してください。

関連概念:

24 ページの『FIPS 準拠』FIPSMode プロパティー com.collation.security.FIPSMode を true に設定することにより、FIPS に準拠する暗号化アルゴリズムを使用するモードで作動するようTADDM を構成することができます。

同期サーバー・デプロイメントのセキュリティー同期サーバー・デプロイメントを使用する場合は、ご使用の環境に応じて同期サーバーを構成する際にセキュリティーの変更を行う必要があります。


http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

TADDM ファイル・ベースのレジストリーの使用中に、TADDM ドメインを同期サーバーに追加する場合は、割り当てられている役割やアクセス・コレクションに対して付与されているアクセス権限を含めて、ドメイン内の既存のユーザーを同期サーバーで再作成する必要があります。Lightweight Directory Access Protocol(LDAP) または WebSphere Federated Repositories ユーザー・レジストリーを使用している場合、TADDM にアクセスするユーザーの許可を同期サーバーに追加する必要があります。

ドメインを同期サーバーに追加する場合、新規ドメインの認証および許可は、同期サーバーに委任されます。

ドメインへのログインは、同期サーバーで処理されます。さらに、セキュリティー・マネージャーのメソッド呼び出しが同期サーバーによって処理されます。

次のリストでは、同期サーバーを構成する場合に知っておく必要があるその他のセキュリティー情報の要約を示します。

v TADDM が正しく機能するためには、同期サーバーでデータ管理ポータルが実行中である必要があります。TADDM ドメインは、セキュリティーの運用をデータ管理ポータルに委任し、この委任は 2.5 分ごとに更新されます。5 分経過してもこの委任が更新されない場合、TADDM ドメインはセキュリティー運用の委任を中止し、同期サーバーが存在しないかのように続行します。この状態では、TADDM UI を再始動して同期サーバーとのセッションを再確立する必要があります。

v 次の各状態では、TADDM UI を再始動して、適切な同期サーバーとのセッションを再確立する必要があります。

– UI を実行しているドメインが、同期サーバーでデータ管理ポータルに追加されます。

– UI は、ドメインがデータ管理ポータルに接続している間、そのドメインで開いていますが、同期サーバーは後で、同期サーバーが再起動する間またはネットワーク障害が発生したときなどに、利用不可になります。

v TADDM サーバーに保管される役割、許可、およびアクセス・コレクションは、ドメインから同期サーバーに対して同期化されます。役割マッピングへのユーザーは同期化されません。

v ドメイン用に作成した役割は、これらのオブジェクトがドメインから同期サーバーに同期された後、同期サーバーで使用できます。

v ユーザーは同期サーバーと同期化されません。

v LDAP または WebSphere Federated Repositories レジストリーのような中央ユーザー・レジストリーは、同期サーバー用の認証方法として優先されます。中央ユーザー・レジストリーを使用して、ユーザー・パスワードは一箇所に保管されます。

v アクセス・コレクションは、複数のドメインにまたがることができません。

v 同期は、ドメインから同期サーバーに対して行われます。同期サーバーで作成されたオブジェクトは、ドメインには伝搬されません。

v ドメインでアクセス・コレクションを作成してデータを取り込み、同期サーバーと同期化します。

v ドメインで役割を作成して、同期サーバーと同期化します。

管理 27

v 同期サーバーでユーザーに権限を与え、複数のドメインからのアクセス・コレクションへのアクセス権限を提供します。

ストリーミング・サーバー・デプロイメントのセキュリティーストリーミング・サーバー・デプロイメントを使用する場合、認証と許可は 1 次ストレージ・サーバーによって代行されます。

TADDM のファイル・ベース・レジストリーを使用する場合は、1 次ストレージ・サーバーで TADDM ユーザーを作成し、権限を与える必要があります。Lightweight Directory Access Protocol (LDAP) または WebSphere FederatedRepositories のユーザー・レジストリーを使用する場合は、1 次ストレージ・サーバーで TADDM ユーザーに権限を与える必要があります。 TADDM 認証で優先されるレジストリー・タイプは、LDAP レジストリーや WebSphere FederatedRepositories レジストリーなどの中央ユーザー・レジストリーです。

ディスカバリー・サーバーおよび 2 次ストレージ・サーバーへのログインは、1 次ストレージ・サーバーで処理されます。したがって、ユーザー認証は 1 次ストレージ・サーバーが構成されているユーザー・レジストリーに対して実行されます。さらに、セキュリティー・マネージャーの機能は 1 次ストレージ・サーバーによって処理されます。

TADDM が正しく機能するためには、1 次ストレージ・サーバーが実行されている必要があります。

1 次ストレージ・サーバーを停止または再始動した場合は、TADDM ユーザー・インターフェースを再始動して、1 次ストレージ・サーバーとのセッションを再確立する必要があります。

LDAP の構成ユーザー認証に外部 LDAP サーバーを構成できます。

始める前に

LDAP ユーザー・レジストリーへの認証を行う場合は、LDAP V2 または V3 レジストリーを構成します。


LDAP または VMM (あるいはその両方) を使用している場合、LDAP ユーザーまたは LDAP グループ (あるいはその両方) は常に LDAP/VMM に格納されるため、TADDM 内に作成する必要はありません。LDAP ユーザーと LDAP グループに役割を割り当てる場合のみ、TADDM が使用されます。これらのユーザー/グループから役割へのマッピング (許可とも呼ばれます) だけを、TADDM で作成して格納する必要があります。管理者ユーザー ID は、特殊な内部 TADDM ユーザーです。このユーザーは、構成されているユーザー・レジストリーにかかわらず、常にファイル・ベースのセキュリティーを使用して処理されます。LDAP ユーザーとLDAP グループに対して最初に役割を割り当てる場合は、常にこのユーザーを使用することができます。


手順

LDAP または VMM をユーザー認証で使用するには、以下の手順を実行します。

1. collation.properties ファイルで適切なプロパティーを構成して、LDAP レジストリーを使用するように TADDM を構成します。

2. TADDM 管理者ユーザー ID を使用して、データ管理ポータルにログインします。

3. 以下のいずれかのステップを実行します。

v 「ユーザー」ペインの「ユーザー検索」フィールドを使用して、適切なユーザーの LDAP レジストリーを検索します。

v 「ユーザー・グループ」ペインの「グループ検索」フィールドを使用して、適切なユーザー・グループの LDAP レジストリーを検索します。

注: 検索結果に、LDAP レジストリー検索で返されたユーザー名またはグループ名がリストされます。これは、ユーザーを作成するための方法でも、LDAP から TADDM にユーザーをコピーするための方法でもありません。このリストの目的は、ユーザー用に作成する必要のある TADDM 許可を表示することです。

4. ユーザー (またはグループ) のリストが表示されたら、必要な TADDM 役割をそのユーザーやグループに割り当ててください。 TADDM に格納されるのは、これらの許可だけです。LDAP ユーザーや LDAP グループは格納されません。

次のタスク

LDAP 用の SSL を構成するには、以下の手順を実行します。

1. collation.properties ファイルで以下のプロパティーを見付け、プロパティーの値を false から true に変更します。

com.collation.security.auth.ldapUseSSL

2. 必要に応じて、以下のトラストストア・プロパティーと鍵ストア・プロパティーを構成します。

com.collation.security.auth.ldapClientKeyStore

com.collation.security.auth.ldapClientKeyStorePassphrase

com.collation.security.auth.ldapClientTrustStore

com.collation.security.auth.ldapClientTrustStorePassphrase

3. 必要に応じて以下のプロパティーを構成し、LDAP サーバーが SSL 接続をlisten するポートを変更します。

com.collation.security.auth.ldapPortNumber

WebSphere Federated Repositories の構成ご使用の Tivoli WebSphere アプリケーションが、WebSphere FederatedRepositories を使用する中央ユーザー・レジストリー用に構成されている場合は、WebSphere Federated Repositories レジストリー用に構成できます。

管理 29

WebSphere Federated Repositories を使用する TADDM サーバーの構成WebSphere Federated Repositories は、WebSphere 内の柔軟性のあるメタ・リポジトリーであり、 Microsoft Active Directory を含む複数のタイプのユーザー・レジストリーをサポートします。

始める前に

ご使用の環境で、他の Tivoli 製品を使用する場合は、WebSphere FederatedRepositories を使用するように TADDM を構成する必要があり、また TADDM と次のいずれかの製品との間のシングル・サインオンが必要です。

v IBM Tivoli Change and Configuration Management Database (CCMDB) または (IBM SmartCloud Control Desk (SCCD))

v IBM Tivoli Business Service Manager

TADDM では、標準の WebSphere の配布に含まれない追加サービスが必要であるため、フェデレーテッド・リポジトリー用に TADDM を構成する場合、以下のいずれかの WebSphere インストール済み環境を使用する必要があります。

v WebSphere Application Server Network Deployment (CCMDB または SCCDが一緒にインストールされている)

v WebSphere Application Server (IBM Tivoli Business Service Manager とともにインストールされるもの)

サポートされる製品バージョンを確認するには、セクション 217 ページの『サポートされるバージョン』を参照してください。

この手順を開始する前に、WebSphere Application Server Network Deploymentサーバー上で既に WebSphere Federated Repositories 認証サービスを構成済みである必要があります。詳しくは、IBM Tivoli Change and ConfigurationManagement Database (CCMDB) の資料、または (IBM SmartCloud ControlDesk (SCCD)) の資料を参照してください。


この構成によって、WebSphere Lightweight Third-Party Authentication (LTPA)トークンを使用した Tivoli アプリケーション間のシングル・サインオンが可能になります。例えば、CCMDB または SCCD で使用されている同じ WebSphereFederated Repositories を使用するように TADDM を構成すると、 IBM TivoliCCMDB または IBM SCCD と TADDM の間のランチ・イン・コンテキストでシングル・サインオンがサポートされます。

WebSphere WebSphere Federated Repositories を使用するように TADDM を自動で構成するには、TADDM をインストールし、インストール中のユーザー・レジストリーとして、「WebSphere Federated Repositories」を選択します。

この構成は、すべてのデプロイメントのすべての TADDM サーバー・タイプでサポートされます。


手順

構成を手動で実行するには、以下のステップを実行します。


2. この TADDM サーバーで使用するユーザー管理モジュールを指定します。有効な値は以下のとおりです。

file この値はファイル・ベースのユーザー・レジストリーに使用します。(これはデフォルト値です。)

ldap この値は LDAP ユーザー・レジストリーに使用します。

vmm この値は WebSphere Application Server の Federated Repositoriesを使用するユーザー・レジストリーに使用します。

例えば、$COLLATION_HOME/etc/collation.properties ファイルでは以下のようになります。

com.collation.security.usermanagementmodule=vmm

3. collation.properties ファイルで、WebSphere ホスト名およびポートを指定します。例:

com.collation.security.auth.websphereHost=localhostcom.collation.security.auth.webspherePort=2809

collations.properties ファイルの WebSphere ポートを指定する際に、com.collation.security.auth.webspherePort プロパティーを使用します。WebSphere ポートは、WebSphere サーバーのブートストラップ・ポートにしてください。 WebSphere Application Server および WebSphere ApplicationServer の組み込みバージョンでは、デフォルト・ポートは 2809 です。 IBMTivoli CCMDB または IBM SCCD が使用する WebSphere ApplicationServer Network Deployment では、デフォルト・ポートは 9809 です。

4. WebSphere 管理者ユーザー名およびパスワードを collation.properties ファイルに指定します。例:

com.collation.security.auth.VMMAdminUsername=administratorcom.collation.security.auth.VMMAdminPassword=password

5. 認証サービス構成ファイルに以下のような変更を加えます。

v Linux、AIX、および Linux on System z オペレーティング・システムの場合、ファイルは、$COLLATION_HOME/etc/

ibmessclientauthncfg.properties にあります。

v Windows オペレーティング・システムの場合、ファイルは%COLLATION_HOME%¥etc¥ibmessclientauthncfg.properties のパスにあります。

authnServiceURL プロパティーで、ご使用の WebSphere インスタンスがインストールされているシステムの完全修飾ドメイン名および WebSphere インスタンスの HTTP ポートを置換します。

# これは認証サービスの URL ですauthnServiceURL=http://localhost:9080/TokenService/services/Trust

6. WebSphere の orb.properties および iwsorbutil.jar ファイルを、ご使用の TADDM インストール済み環境で使用している JRE にコピーします。例えば、 TADDM Linux インストール済み環境では、以下を実行します。

管理 31

a. dist/lib/websphere/6.1/orb.properties を dist/external/jdk-Linux-i686/jre/lib/ にコピーします。

b. dist/lib/websphere/6.1/iwsorbutil.jar を dist/external/jdk-Linux-i686/jre/lib/ext/ にコピーします。

7. 以下のように、sas.client.props ファイルに WebSphere ホスト名およびポートを指定します。

v Linux、AIX、および Linux on System z オペレーティング・システムの場合、このファイルは、パス $COLLATION_HOME/etc/sas.client.props にあります。

v Windows オペレーティング・システムの場合、ファイルは%COLLATION_HOME%¥etc¥sas.client.props のパスにあります。例えば、以下のようになります。

com.ibm.CORBA.securityServerHost=host1.austin.ibm.comcom.ibm.CORBA.securityServerPort=2809

注: WebSphere Application Server および WebSphere Application Serverの組み込みバージョンでは、デフォルト・ポートは 2809 です。 IBM TivoliCCMDB または IBM SCCD が使用する WebSphere Application ServerNetwork Deployment では、デフォルト・ポートは 9809 です。

8. WebSphere 管理者ユーザー名およびパスワードを sas.client.props ファイルで指定します。例:

# RMI/IIOP ユーザー IDcom.ibm.CORBA.loginUserid=administratorcom.ibm.CORBA.loginPassword=password

9. オプション: sas.client.props ファイルのログイン・パスワードを暗号化するには、以下のステップを実行します。

a. sas.client.props ファイルを TADDM サーバーの $COLLATION_HOME/etcディレクトリーにコピーします。

b. WebSphere をインストールしたオペレーティング・システムに応じて、パスワードを以下のように暗号化します。

v Linux、AIX および Linux on System z オペレーティング・システムの場合:

PropFilePasswordEncoder.sh コマンドを使用します。

v Windows オペレーティング・システムの場合:

PropFilePasswordEncoder.bat を使用します。例えば、次のようになります。

C:¥WebSphere¥profiles¥AppSrv01¥bin¥PropFilePasswordEncoder C:¥temp¥sas.client.props com.ibm.CORBA.loginPassword

c. sas.client.props ファイルを TADDM サーバーの etc ディレクトリーにコピーします。

10. TADDM サーバーを開始してください。

次のタスク

インストールの完了後に、ローカルの TADDM ファイル・ベース・リポジトリーで定義されたデフォルト管理ユーザーを使用して、TADDM 管理者を含む追加の


TADDM ユーザーを構成できます。これらの追加の TADDM ユーザーは、WebSphere Federated Repositories を使用して認証されます。

グループおよびグループ・メンバーシップを Maximo® ユーザーおよびグループ・アプリケーション内に作成して維持できるようにする、Tivoli CCMDB または IBMSCCD 用のセキュリティー構成があります。

Tivoli CCMDB または IBM SCCD がこのために構成されると、TADDM は独自の別個のリポジトリーを Tivoli CCMDB または IBM SCCD から使用します。Tivoli CCMDB or IBM SCCD/Maximo と TADDM の両方でユーザーが作成される必要があります。

TADDM は、WebSphere Federated Repositories を通じ、外部ユーザー・レジストリーでユーザーおよびグループ定義を使用するように構成することができます。ただし、TADDM は、Tivoli CCMDB に保管されているユーザーおよびグループ定義を使用できません。これらの定義は、WebSphere Federated Repositories でサポートされていないためです。

認証サービスの LTPA 鍵の更新WebSphere Federated Repositories でシングル・サインオンを使用している場合、認証サービスの Lightweight Third-Party Authentication (LTPA) 鍵が、WebSphere Federated Repositories で使用する鍵と同期している状態を維持する必要があります。

手順

WebSphere Federated Repositories が使用する LTPA 鍵が変更された場合、以下のプロセスを実行して、認証サービスが使用する鍵を再同期化します。

1. 新規 WebSphere LTPA 鍵をエクスポートします。

a. WebSphere 管理コンソールで、「管理、アプリケーション、およびインフラストラクチャーの保護」 > 「認証メカニズムと有効期限」にナビゲートします。

b. 「クロス・セル・シングル・サインオン」に、エクスポートされた LTPA鍵を含むファイルのファイル名およびパスワードを指定します。

2. コマンド・プロンプトで、適切な WebSphere プロファイルの bin ディレクトリーにナビゲートします。

3. 以下の WebSphere wsadmin コマンドを実行します。

wsadmin> $AdminTask importESSLTPAKeys {-pathname pathname -password password}

ここで、pathname および password は、LTPA 鍵のエクスポート時にファイル名とパスワードに指定した値です。

4. WebSphere サーバーを再始動します。

認証チャネルの保護WebSphere WebSphere Federated Repositories を使用するように TADDM を構成する場合は、認証クライアントと認証サービスの間の通信を保護することができます。

管理 33


TADDM は、シングル・サインオンをサポートする認証サービスを使用します。認証サービスは、 IBM Tivoli Change and Configuration Management Database(IBM SmartCloud Control Desk (SCCD)) または IBM Tivoli Business ServiceManager のインストール中にインストールされます。


認証クライアントと認証サービスの間の通信を保護するには、以下の 2 つのメカニズムを使用できます。

v SSL

v クライアント認証

SSL 用の認証チャネルの構成:

WebSphere 署名者証明書を使用して、認証クライアントと認証サーバー間で SSLを構成すると、通信を保護することができます。

手順

認証クライアントと認証サーバーの間の SSL を構成するには、以下のステップを実行します。

1. 以下のいずれかを行います。

a. Tivoli Integrated Portal によってインストールされた WebSphere インスタンスを使用している場合は、「SSL 証明書および鍵管理」 > 「エンドポイント・セキュリティー構成の管理」 > 「Node1」 > 「鍵ストアおよび証明書」 > 「NodeDefaultTrustStore」 > 「署名者証明書」にナビゲートします。

b. Tivoli Change and Configuration Management Database (CCMDB) または IBM SmartCloud Control Desk によってインストールされたWebSphere インスタンスを使用している場合は、「SSL 証明書および鍵管理」 > 「エンドポイント・セキュリティー構成の管理」 > 「ctgNode01」> 「鍵ストアおよび証明書」 > 「NodeDefaultTrustStore」 > 「署名者証明書」にナビゲートします。

2. WebSphere 署名者証明書をファイルにエクスポートします (例えば、exportdummyclientsigner を signer1.cert にエクスポートし、 dummyserversignerを signer2.cert にエクスポートします)。どの証明書をエクスポートすればよいか不確定な場合は、署名者証明書をすべてエクスポートする必要があります。

3. .cert ファイルを TADDM サーバーにコピーします。以下のとおりに、トラスト・ストアを作成して WebSphere 署名者証明書をインポートします。

$COLLATION_HOME/external/jdk-Linux-i686/jre/bin/keytool ¥-genkey -alias truststore -keystore truststore.jks$COLLATION_HOME/external/jdk-Linux-i686/jre/bin/keytool ¥-import -trustcacerts -alias default -file signer1.cert -keystore truststore.jks$COLLATION_HOME/external/jdk-Linux-i686/jre/bin/keytool ¥-import -trustcacerts -alias dummyserversigner -file signer2.cert -keystore truststore.jks

4. トラストストアのパスワードおよびロケーションを $COLLATION_HOME/etc/collation.properties 項目に以下のように組み込みます。


com.collation.security.auth.ESSClientTrustStore=/opt/IBM/taddm/dist/etc/truststore.jkscom.collation.security.auth.ESSClientTrustPwd=password

5. ibmessclientauthncfg.properties ファイル内の Tivoli Authentication ServiceURL を、https およびポート 9443 を使用するように更新します。 WebSphereホスト名が正しく、それを localhost の代わりにしていること、および https以外の項目がコメント化されていることを確認してください。

# これは ESS 認証サービスの URL です#authnServiceURL=http://localhost:9080/TokenService/services/TrustauthnServiceURL=https://localhost:9443/TokenService/services/Trust

クライアント認証の構成:

認証クライアントと認証サーバーの間のクライアント認証を構成するには、WebSphere のアプリケーション・セキュリティーを使用可能にすることをお勧めします。

始める前に

WebSphere アプリケーション・セキュリティーを有効にすると、 TADDM のインストール中に指定した WebSphere 管理者ユーザーに TrustClientRole という役割を追加できます。このメソッドにより、認証サービスにセキュリティーが追加され、認証サービスに対して認証可能なユーザーが TrustClientRole を持つユーザーのみに制限されます。

手順

TADDM のインストール中に指定した WebSphere 管理者に TrustClientRole を追加するには、以下のステップを実行します。

1. WebSphere 管理コンソールにログインします。

2. 「セキュリティー」タブで、「エンタープライズ・アプリケーション」をクリックします。「エンタープライズ・アプリケーション」ペインが表示されます。

3. 「エンタープライズ・アプリケーション」テーブルで、「名前」列の認証サービス・アプリケーション (authnsvc_ctges) をクリックします。「エンタープライズ・アプリケーション」 >「authnsvc_ctges」ペインが表示されます。

4. 「エンタープライズ・アプリケーション」>「authnsvc_ctges」ペインの「詳細プロパティー (Detailed Properties)」リストで、「ユーザー/グループ・マッピングへのセキュリティー・ロール」をクリックします。「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」ペインが表示されます。

5. 「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」ペインにあるテーブルで、以下のステップを実行します。

v テーブル内で、TrustClientRole の横のチェック・ボックスを選択します。

v 「全員」チェック・ボックスをクリアします。

v 「ユーザーのルックアップ」または「グループのルックアップ」をクリックします。「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」>「ユーザーのルックアップ」または「グループのルックアップ」ペインが表示されます。

管理 35

v 「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」>「ユーザーのルックアップ」または「グループのルックアップ」ペインで、以下のステップを実行します。

– 「ストリングの制限と検索 (Limit and Search string)」入力ボックスを使用して、ユーザーまたはグループを検索します。グループまたはユーザーが検出されると、使用可能リストに表示されます。

– 使用可能リストから、必要なユーザーまたはグループを選択します。

– 「移動」をクリックして、ユーザーまたはグループを「選択済み」リストに追加します。

v 「OK」をクリックします。「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」ペインが表示されます。

v 「エンタープライズ・アプリケーション」>「authnsvc_ctges」>「ユーザー/グループ・マッピングへのセキュリティー・ロール」ペインで、「全員」チェック・ボックスをクリアします。

v 「OK」をクリックします。「エンタープライズ・アプリケーション」>「authnsvc_ctges」ペインが表示されます。

v 「保管」をクリックして、構成を保管します。「エンタープライズ・アプリケーション」ペインが表示されます。

v 「OK」をクリックします。「エンタープライズ・アプリケーション」>「authnsvc_ctges」ペインが表示されます。

Microsoft Active Directory 用の構成WebSphere Federated Repositories を仲介として使用して Microsoft ActiveDirectory を TADDM の認証方式として使用することができます。 TADDM へのシングル・サインオンが必要な場合は、WebSphere Federated Repositories を使用する必要があります。


新規ユーザーを定義せずに、Active Directory レジストリーで定義されたユーザーを使用することができます。そのためには、 Active Directory を使用するようにTADDM を構成します。Active Directory を LDAP レジストリーとして使用するように TADDM を構成するか、または WebSphere Federated Repositories を使用するように TADDM を構成してから、Active Directory 用に WebSphereFederated Repositories を構成することができます。

TADDM のインストール時に Active Directory 用の構成を行う場合は、ActiveDirectory の任意のユーザーを TADDM 管理者として使用するように TADDM を構成することができます。この管理者は、TADDM へのアクセス権限を構成したり、他のユーザーに TADDM オブジェクトおよびサービスへのアクセス権限を付与したりできます。

この構成は、すべてのデプロイメントのすべての TADDM サーバー・タイプでサポートされます。


手順

Microsoft Active Directory 用に構成するには、次のステップを実行します。

以下のいずれかを行います。

v LDAP を使用して Microsoft Active Directory を構成するには、以下のようにします。

1. LDAP 用に TADDM を構成します。LDAP 用の TADDM の構成について詳しくは、 28 ページの『LDAP の構成』を参照してください。

2. Active Directory を使用しているときに、必ず collation.properties ファイルで com.collation.security.auth.ldapFollowReferrals を true に設定してください。

v WebSphere Federated Repositories を使用して Microsoft Active Directory を構成するには、以下のようにします。

1. WebSphere Federated Repositories 用に TADDM を構成します。WebSphere Federated Repositories 用の TADDM の構成について詳しくは、 30 ページの『WebSphere Federated Repositories を使用するTADDM サーバーの構成』を参照してください。

2. Microsoft Active Directory 用に WebSphere Federated Repositories を構成します。フェデレーテッド・リポジトリー構成におけるサポートありのエンティティー・タイプの構成について詳しくは、「WebSphere ApplicationServer インフォメーション・センター」の『フェデレーテッド・リポジトリー構成におけるサポートありのエンティティー・タイプの構成』というセクション (http://www-01.ibm.com/support/knowledgecenter/SSAW57_6.1.0/com.ibm.websphere.nd.doc/info/ae/ae/twim_entitytypes.html) を参照してください。

TADDM Web サービスの保護collation.properties の com.ibm.cdb.secure.tomcat プロパティー (TADDM7．3.0) または com.ibm.cdb.secure.liberty プロパティー (TADDM 7.3.0.1 以降)を true に設定すると、HTTP ポートを無効にするように TADDM を構成できます。また、com.ibm.cdb.http.ssl.protocol フラグを使用すると、より安全な SSLプロトコルを設定できます。

com.ibm.cdb.secure.tomcat プロパティーおよび com.ibm.cdb.secure.liberty プロパティーのデフォルト値は false です。 HTTP ポートを無効にした場合は、HTTPS ポートでのみ TADDM にアクセスできます (例: https://

example.com:9431)。

制限: TADDM をストリーミング・サーバー・デプロイメント環境にインストール済みで、ディスカバリー・サーバーと 2 次ストレージ・サーバーが稼働中の場合、com.ibm.cdb.secure.tomcat プロパティーまたは com.ibm.cdb.secure.liberty プロパティーを true に設定できます。この場合、HTTP ポートは無効になるため、TADDM をセキュア・モードで使用できます。ただし、新規ディスカバリー・サーバーまたは 2 次ストレージ・サーバーをデプロイメント環境に追加する場合は、TADDM インストーラーで HTTPS プロトコルがサポートされていないため、HTTP ポートを一時的に有効にする必要があります。セキュア・モードを一時的に無効にするには、以下の手順を実行します。

管理 37

http://www-01.ibm.com/support/knowledgecenter/SSAW57_6.1.0/com.ibm.websphere.nd.doc/info/ae/ae/twim_entitytypes.html



1. com.ibm.cdb.secure.tomcat プロパティーまたは com.ibm.cdb.secure.libertyプロパティーの値を false に変更します。


3. 新規ディスカバリー・サーバーまたは 2 次ストレージ・サーバーをインストールします。

4. com.ibm.cdb.secure.tomcat プロパティーまたは com.ibm.cdb.secure.libertyプロパティーの値を true に変更します。


com.ibm.cdb.http.ssl.protocol プロパティーのデフォルト値は TLS です。安全な値は、TLS、TLSv1.1、および TLSv1.2 です。最も安全なプロトコルである TLSv1.1と TLSv1.2 を使用する場合は、最初に、これらのプロトコルをサポートするようにWeb ブラウザーを構成する必要があります。

TADDM での使用を目的としたカスタマイズした SSL 証明書のインストール

独自にカスタマイズした SSL 証明書をインストールして、TADDM で使用できます。

手順1. 以下の鍵ストア・ファイルのバックアップ・コピーを作成します。

v $COLLATION_HOME/etc/serverkeys

v $COLLATION_HOME/etc/jssecacerts.cert

2. $COLLATION_HOME/etc ディレクトリーに移動し、コマンド行を開いて、keytool

パラメーターと TADDM sslpassphrase パラメーターをその値とともに以下のように入力します。

v Linux オペレーティング・システム:

keytool=../external/jdk-Linux-x86_64/bin/keytoolpass=XXXXXXXX30374

v Windows オペレーティング・システム:

set keytool=..¥external¥jdk-Windows-i386-64¥bin¥keytool.exeset pass=XXXXXXXX30374

pass パラメーターの値は、collation.properties ファイルに指定されているcom.collation.sslpassphrase プロパティーの値です。

3. 以下のコマンドを実行して、自己署名証明書とキーを TADDM から除去します。


$keytool -delete -alias collation -noprompt -keystore jssecacerts.cert-storepass $pass$keytool -delete -alias collation -noprompt -keystore serverkeys -storepass$pass


%keytool% -delete -alias collation -noprompt -keystore jssecacerts.cert-storepass %pass%%keytool% -delete -alias collation -noprompt -keystore serverkeys -storepass%pass%


4. 必要な CN、有効期間、アルゴリズム、およびその他のパラメーターを指定してSSL 鍵を生成し、serverkeys ファイルに保存します。例えば、以下のコマンドを実行できます。


$keytool -genkey -alias collation -keystore serverkeys -validity 3650-keyAlg RSA -sigalg SHA256WithRSA -keypass $pass -storepass $pass -dname"CN=John Public, OU=Engineering, OU=NA, o=Company, L=Manhattan,S=New York, c=US"


%keytool% -genkey -alias collation -keystore serverkeys -validity 3650-keyAlg RSA -sigalg SHA256WithRSA -keypass %pass% -storepass %pass% -dname"CN=John Public, OU=Engineering, OU=NA, o=Company, L=Manhattan,S=New York, c=US"

5. 生成した SSL 鍵を保存した serverkeys ファイルのバックアップ・コピーをもう 1 つ作成します。

6. 以下のコマンドを実行して、証明書署名要求 (CSR ファイル) を生成します。


$keytool -certreq -alias collation -storepass $pass -file/tmp/certreq.csr -keystore serverkeys


%keytool% -certreq -alias collation -storepass %pass% -fileC:¥temp¥certreq.csr -keystore serverkeys

7. CSR ファイルを使用して、SSL 証明書を正式な認証局から取得します。証明書を TADDM サーバーに保存します。例えば、Linux オペレーティング・システムでは tmp ディレクトリーに、Windows オペレーティング・システムではC:¥temp ディレクトリーに、cert.crt ファイルとして保存します。

8. 以下のコマンドを実行して、生成された証明書を TADDM (serverkeys ファイルと jssecacerts.cert ファイルの両方) にインポートします。

重要: -file パラメーターについては、前のステップで SSL 証明書を保存したファイルへのパス (例: Linux オペレーティング・システムでは/tmp/cert.crt、Windows オペレーティング・システムではC:¥temp¥cert.crt) を指定します。


$keytool -import -trustcacerts -alias collation -noprompt -keystoreserverkeys -storepass $pass -keypass $pass -file /tmp/cert.crt$keytool -import -trustcacerts -alias collation -noprompt -keystorejssecacerts.cert -storepass $pass -keypass $pass -file /tmp/cert.crt


%keytool% -import -trustcacerts -alias collation -noprompt -keystoreserverkeys -storepass %pass% -keypass %pass% -file C:¥temp¥cert.crt%keytool% -import -trustcacerts -alias collation -noprompt -keystorejssecacerts.cert -storepass %pass% -keypass %pass% -file C:¥temp¥cert.crt


管理 39

次のタスク

ステップ 4 で生成した serverkeys ファイルのバックアップ・コピーと、ステップ7 で SSL 証明書を保存したファイルを保持します。証明書の置き換えや更新が必要な場合に、これらのファイルが必要となります。証明書の置き換えまたは更新を行うには、以下のステップを実行します。

1. ステップ 2 と 3 を繰り返します。

2. serverkeys ファイルを復元します。

3. ステップ 8 と 9 を繰り返します。

TADDM サーバーの管理ディスカバリー用に TADDM を構成する前に、TADDM サーバーの管理方法 (これには多くの作業が含まれます) を理解する必要があります。

TADDM サーバーの状況の確認TADDM サーバーの状況は、管理者コンソールまたは control コマンドを使用して確認できます。

管理者コンソールによる状況の確認

管理者コンソールを使用して状況を確認するには、Web ブラウザーを開いて、TADDM サーバーをインストールしたシステムの URL とポート番号を入力します。例えば、次のような URL を指定します。

http://system.company.com:9430

管理者コンソールが表示され、TADDM サーバーのコンポーネントとその状況がリストされます。

control コマンドによる状況の確認

control コマンドを使用して状況を確認するには、以下のステップを実行します。

1. インストール・プロセス中に定義された非 root ユーザーとしてログインします。

2. コマンド・プロンプトから、TADDM サーバーをインストールしたディレクトリーに移動します。

3. 以下のコマンドのいずれかを実行します。

v AIX、Linux、および Linux on System z オペレーティング・システムの場合:

$COLLATION_HOME/bin/control status


%COLLATION_HOME%¥bin¥control.bat status

現在のデプロイメント環境と、それぞれのデプロイメント環境で TADDM が稼働しているサーバーのタイプに応じて、以下の出力が表示されます。

同期サーバー・デプロイメント

同期サーバー


v TADDM 7.3.0:

DbInit: 開始済みTomcat: 開始済みEcmdbCore: 開始済み

TADDM: 実行中

v TADDM 7.3.0.1 以降:

DbInit: 開始済みLiberty: 開始済みEcmdbCore: 開始済み

TADDM: 実行中

ドメイン・サーバー

v TADDM 7.3.0:

Discover: 開始済みDbInit: 開始済みTomcat: 開始済みTopology: 開始済みDiscoverAdmin: 開始済みProxy: 開始済みEventsCore: 開始済み

TADDM: 実行中


Discover: 開始済みDbInit: 開始済みLiberty: 開始済みTopology: 開始済みDiscoverAdmin: 開始済みProxy: 開始済みEventsCore: 開始済み

TADDM: 実行中

ストリーミング・サーバー・デプロイメント

ストレージ・サーバー

v TADDM 7.3.0:

TADDM: 開始中EtaddmCore: 開始済みDbInit: 開始済みTomcat: 開始済み

TADDM: 実行中


TADDM: 開始中EtaddmCore: 開始済みDbInit: 開始済みLiberty: 開始済み

TADDM: 実行中

ディスカバリー・サーバー

v TADDM 7.3.0:

Discover: 開始済みTomcat: 開始済みDiscoverAdmin: 開始済み

管理 41

ProxyLite: 開始済みEventsCore: 開始済み

TADDM: 実行中


Discover: 開始済みLiberty: 開始済みDiscoverAdmin: 開始済みProxyLite: 開始済みEventsCore: 開始済み

TADDM: 実行中

TADDM サーバーの始動インストール時に「ブート時に開始 (Start at Boot)」オプションを選択した場合、TADDM サーバーはシステム・ブートごとに自動的に始動します。


重要: ローカルまたはリモート・データベース・サーバーは、 TADDM サーバーが始動する前に、始動して実行されている必要があります。データベースが使用不可の場合、 TADDM サーバーは正常に初期化または実行することができません。

手順

TADDM サーバーを手動で始動するには、以下のステップを実行します。


2. コマンド・プロンプト・ウィンドウを開きます

注: ユーザーアカウント制御をオンとした Windows Server 2008 システムの場合、管理者特権を使用して、「コマンドプロンプト」ウィンドウを開きます。これは、「コマンドプロンプト」アイコンを右クリックし、「管理者として実行」をクリックすることにより、行うことができます。

3. TADDM サーバーがインストールされているディレクトリーに移動します。

4. 以下のコマンドのいずれかを使用して、開始スクリプトを実行します。


$COLLATION_HOME/bin/control start


%COLLATION_HOME%¥bin¥startServer.bat

Windows システム上でサーバーを始動すると、次のタイムアウト・エラー・メッセージが表示されることがあります。エラー 1053: サービスが始動または制御要求にタイムリーに対応しませんでした。(Error 1053: The service did not

respond to the start or control request in a timely fashion.) このエラーが発生するのは、 TADDM サーバーが、許可された時間よりも始動に長くかかっている可能性があるためです。このメッセージは無視して構いません。始動プロセスは完了するまで続行されます。


TADDM サーバーを root 特権でインストールした場合は、次のスクリプトを実行することで TADDM サーバーを手動で始動できます。

/etc/init.d/collation start

TADDM サーバーの停止TADDM サーバーおよび関連するディスカバリー・プロセスを手動で停止できます。

手順

TADDM サーバーを手動で停止するには、以下のステップを実行します。



注: ユーザーアカウント制御をオンとした Windows Server 2008 システムの場合、管理者特権を使用して、「コマンドプロンプト」ウィンドウを開きます。これは、「コマンドプロンプト」アイコンを右クリックし、「管理者として実行」をクリックすることにより、行うことができます。

3. TADDM サーバーがインストールされているディレクトリーに移動します。

4. 以下のコマンドのいずれかを使用して、停止スクリプトを実行します。


$COLLATION_HOME/bin/control stop


%COLLATION_HOME%¥bin¥stopServer.bat

TADDM サーバーを root 特権でインストールした場合は、次のスクリプトを実行することで TADDM サーバーを手動で停止できます。

/etc/init.d/collation stop

次のタスク

一部のセンサーは、独自の特殊な Java 仮想マシン (JVM) で実行されます。ディスカバリーの実行中にコントロール・スクリプト (./control stop) を使用してTADDM を停止する場合、それらの追加 JVM (ローカル・アンカーと呼ばれる) を手動で停止しなければならない場合があります。ローカル・アンカーを停止しない場合は、予期しない動作が発生することがあります。例えば、特定のディスカバリーのパフォーマンスが低下する場合があります。

ローカル・アンカーのプロセスが実行されていないことを確認するには、次のコマンドを入力します。

% ps -ef |grep -i anchor

このコマンドにより、実行中のローカル・アンカー・プロセスがすべて識別されます。出力は以下のコード例のようになります。

coll 23751 0.0 0.0 6136 428 ? S Jun02 0:00 /bin/shlocal-anchor.sh 8494 <more information here>

管理 43

プロセスが実行されている場合は、次のコマンドを実行してプロセスを停止します。

- % kill -9 23751

コマンドを実行した後で、次のコマンドを実行して、プロセスが停止したことを確認します。

% ps -ef |grep -i anchor

データのバックアップシステム障害から回復できるように、データを定期的にバックアップします。

始める前に

データをバックアップする前に、TADDM サーバーを停止してください。

手順

TADDM サーバーのファイルをバックアップするには、以下のタスクを実行します。

TADDM サーバーがインストールされているディレクトリー内のすべてのファイルを保存します。

v Linux、AIX、および Linux on System z オペレーティング・システムの場合、このディレクトリーへのデフォルト・パスは /opt/IBM です。

v Windows オペレーティング・システムの場合、このディレクトリーへのデフォルト・パスは C:¥opt¥IBM です。

次のタスク

データベース・ファイルをバックアップするには、データベース・ベンダーが用意している資料を参照してください。

データの復元システム障害が発生した後、構成ファイル、データ・ファイル、およびデータベース・ファイルを復元することができます。このため、障害が発生する前の最後のバックアップ時点から操作を再開することができます。

手順

バックアップ・メディアからデータを復元するには、以下のステップを実行します。

1. 以下のいずれかを行います。

v /opt/IBM ディレクトリーを復元して、 TADDM を再始動します。

v C:¥opt¥IBM ディレクトリーを復元して、 TADDM を再始動します。

2. データ・ファイルのバックアップ・コピーの場所を探します。


4. TADDM サーバーがインストールされているディレクトリーにナビゲートします。


5. データ・ファイルのバックアップ・コピーをインストール・ディレクトリーにコピーします。

6. コマンド・プロンプト・ウィンドウを閉じます。

7. TADDM サーバーを開始してください。

次のタスク

データベースがシステム障害の影響を受けている場合は、データベース・ベンダーの資料に従ってデータベース・ファイルを復元します。

TADDM サーバー間でのディスカバリー・スコープ、ディスカバリー・プロファイル、およびカスタム・サーバー・テンプレートのコピー

datamover.sh|bat コマンドを使用して、TADDM サーバー間でディスカバリー・スコープ、ディスカバリー・プロファイル、およびカスタム・サーバー・テンプレートをコピーすることができます。

ディスカバリー・スコープ、ディスカバリー・プロファイル、およびカスタム・サーバー・テンプレート (すべてのエンティティー) をエクスポートするか、またはサーバーからエクスポートするエンティティーを指定できます。その後に、宛先サーバーでエンティティーをインポートできます。

制約事項: データ保全性を維持するために、同じバージョンの TADDM サーバーの間でデータを移動する必要があります。

TADDM サーバー間でエンティティーをコピーするには、以下のステップを実行します。

1. ソース・サーバーで以下のコマンドを実行して、必要なエンティティーをファイルにエクスポートします。

datamover.sh|bat -u user -p password -a action [-t type ] [-f filename]

ここで、

user

TADDM ユーザー名。

password

TADDM ユーザのパスワード。

action

import、export、help のいずれかのアクションを指定します。

オプション: type

all、scope、profile、template のいずれかのアクションを指定します。デフォルト値は all です。

オプション: filename

ファイル名を指定してください。デフォルト値は datamover.xml です。

デフォルトのディスカバリー・プロファイルはエクスポートされません。カスタム・サーバー・テンプレート、ユーザー作成のプロファイル、およびスコープはすべてエクスポートできます。

管理 45

コマンドの実行後、エクスポートされたエンティティーの情報が表示されます。例えば、出力ファイルが exporthost.xml の場合、以下の情報が提供されます。

Exported 6 scopesExported 1 profilesExported 57 templates

2. ファイルを宛先サーバーにコピーし、datamover.sh|bat を実行し、エンティティーをインポートします。

エンティティーをインポートする際には、以下の規則が適用されます。

v サーバーに同じ名前のスコープまたはプロファイルが存在する場合は、インポートされるスコープまたはプロファイルの名前が変更されます。ファイル名を name_TADDM に変更します。

v サーバーに同じ名前のテンプレートが存在する場合は、インポートされるテンプレートが既存のテンプレートにマージされます。

ディスカバリー管理コンソールのデプロイディスカバリー管理コンソールは、TADDM サーバーが使用可能であることを確認した後にデプロイできます。

手順

ディスカバリー管理コンソールをデプロイするには、以下のステップを実行します。

1. TADDM サーバーがインストールされているシステムの URL (ポート番号を含む) をユーザーに提供します。

例えば、ユーザーに以下のような URL を提供できます。

http://system.company.com:9430

2. ユーザーにユーザー名およびパスワードを提供します。

3. ユーザーが Secure Sockets Layer (SSL) を使用する必要があるかどうかを指定します。

SSL が使用されている場合、ディスカバリー管理コンソールのインストールおよび開始のページの指示に従って、TADDM サーバー用のトラストストアを保存するようにユーザーに指示します。詳しくは、TADDM の「インストール・ガイド」を参照してください。

重要: ディスカバリー管理コンソールおよび TADDM サーバー間のすべての通信に対して SSL を使用する必要があります。

4. ユーザーは、ディスカバリー管理コンソールを表示するために使用するシステムに、サポートされる Java ランタイム環境をインストールしておく必要があります。クライアントの前提条件について詳しくは、TADDM の「インストール・ガイド」を参照してください。

5. ディスカバリー管理コンソールを開始する方法については、TADDM の「ユーザーズ・ガイド」を参照してください。


TADDM 通信の構成TADDM 通信を確立するには、すべての必要なサービス、接続、およびファイアウォールを構成する必要があります。

TADDM サービス

TADDM 接続は、以下の 3 つの領域に分割できます。

パブリック接続パブリック接続は、TADDM インフラストラクチャーの外部から実行されるネットワーク接続を対象とします。例えば、TADDM サーバーに接続するデータ管理ポータル、ディスカバリー管理コンソール、API クライアントなどです。これは、最上位の接続です。

サーバー間接続サーバー間接続は、TADDM コア・インフラストラクチャーのエレメント間、つまりディスカバリー・サーバーとストレージ・サーバーとの間のネットワーク接続を扱います。これは、中位の接続です。

ローカル接続ローカル接続は、1 台のマシン上のローカル・サービス間のネットワーク接続を扱います。これは、最下位の接続です。

各サービスの接続は、インストール・フェーズ中に構成することも、collation.properties 構成ファイルの構成プロパティーを変更することにより後で構成することもできます。

サービスのデフォルトのインターフェースサービスのデフォルトの listen インターフェースを構成するには、collation.properties ファイルの com.ibm.cdb.global.hostname プロパティーを変更します。

表 2. サービスのデフォルトのインターフェース設定

名前構成プロパティーデフォルトのインターフェース

グローバル・サービス・ホスト

com.ibm.cdb.global.hostname 0.0.0.0

通信のタイプに応じた listen インターフェース各接続領域のサービスに対して listen インターフェースを個別に構成するには、collation.properties ファイル内の該当のプロパティーを変更します。

表 3. サービスのデフォルトのインターフェース設定


パブリック接続サービス・ホスト

com.ibm.cdb.public.hostname com.ibm.cdb.global.hostname で定義

サーバー間接続サービス・ホスト

com.ibm.cdb.interserver.hostname com.ibm.cdb.global.hostname で定義

管理 47

表 3. サービスのデフォルトのインターフェース設定 (続き)


ローカル接続サービス・ホスト

com.ibm.cdb.local.hostname 127.0.0.1

注: インターフェースが指定されていない場合、またはインターフェースの値が 0.0.0.0. の場合は、1 つのローカル外部ネットワーク・インターフェースがそれ自体と通信できる状態である必要があります。インターフェースが指定されている場合は、そのインターフェースがそれ自体と通信できる状態である必要があります。

特定のサービスの listen インターフェース

各サービスの個別の TCP ポートは、インストール・フェーズ中に構成することも、collation.properties ファイルのそれぞれのプロパティーを変更することにより後で構成することもできます。

サービス・インターフェースの構成各サービスに対して特定の listen インターフェースを構成するには、collation.properties ファイル内の host サフィックスを持つ該当のプロパティーを変更します。

TopologyManager サービスの例:

com.ibm.cdb.service.TopologyManager.host=192.168.1.5

注: この命名規則は、パブリック・サービス・レジストリーやサーバー間サービス・レジストリーにはあてはまりません。

サービス・ポートの構成各サービスに対して特定の listen ポートを構成するには、collation.properties ファイル内の port サフィックスを持つ該当のプロパティーを変更します。

以下に、TopologyManager サービスの場合の例を示します。

com.ibm.cdb.service.TopologyManager.port=9550

SSL サービスの構成

各 SSL サービスに特定の listen インターフェース、または listen ポートを構成するには、collation.properties ファイル内の secure インフィックスを持つ該当のプロパティーを変更します。

以下に、SecureApiServer サービスの場合の例を示します。

v com.ibm.cdb.service.SecureApiServer.secure.host=192.168.1.5

v com.ibm.cdb.service.SecureApiServer.secure.port=9531

Web ポータル・インターフェース (HTTP および HTTPS) の構成

Web ポータル (HTTP および HTTPS) 用 listen インターフェースを構成するには、collation.properties ファイルの com.ibm.cdb.service.web.host プロパティーを変更します。


注: HTTP ホストおよび HTTPS ホストは、その他のサービスに照らし合わせて 1つのプロパティーを変更することにより構成されます。

データベース接続

特定のデータベース接続を構成するには、collation.properties ファイル内のcom.collation.db.port プロパティーと com.collation.db.server プロパティーを変更します。

例えば、以下のとおりです。

v com.collation.db.port=65432

v com.collation.db.server=9.156.47.156

DNS 接続

通信用に完全修飾ドメイン名 (FQDN) を使用する場合は、通信に参加するホストがDNS サービスから FQDN を解決できることを確認してください。

センサー接続

ping センサーとポート・センサーが接続を確立するために使用するポートの構成については、ping センサーとポート・センサーの資料に記載されています。ディスカバー対象のサービス用のポートが開いていることを確認してください。

表 4. ping センサーおよびポート・センサーのデフォルトのポート

ポート名デフォルト・ポートプロトコル

SSH 22 TCP

Telnet 23 TCP

DNS 53 TCP

WMI 135 TCP

Fix Pack 2 PowerShell5985, 5986 TCP

LDAP 389 TCP

SMB 445 TCP

Oracle 1521 TCP

CiscoWorks 1741 TCP

アンカー接続

ssh と direct のいずれかの接続タイプを使用して、TADDM からアンカー・サーバーに接続することができます。特定のアンカー接続タイプを構成するには、collation.properties ファイル内の com.collation.discover.anchor.connectTypeプロパティーの値を、ssh または direct のいずれかに変更します。

特定のアドレスの特定のアンカー接続タイプを構成するには、collation.properties ファイルで、IP アドレスをサフィックスとして持つcom.collation.discover.anchor.connectType プロパティーを変更します。以下に例を示します。

com.collation.discover.anchor.connectType.1.2.3.4=direct

管理 49

また、アンカー・サーバーへの接続のデフォルトのポートとして、ポート 8497 が定義されています。ディスカバリー管理コンソールを使用することで、このポートを構成できます。

v ssh モードの場合、SSH 通信用のポートは、TADDM サーバーからアクセスされるパブリック・インターフェース上で開き、アンカー接続ポートは、アンカー・サーバーをホストするマシンのループバック・インターフェース上で開きます。

v direct モードでは、TADDM サーバーからアクセスされるパブリック・インターフェース上の SSH 通信用およびアンカー接続用のポートを開きます。

ゲートウェイ接続

SSH 接続を使用して、TADDM からゲートウェイ・サーバーに接続することができます。

ゲートウェイでは、TADDM サーバーからアクセスされるパブリック・インターフェース上で通信用にホスト SSH ポートが開かれている必要があります。

サーバー・ホスト名の完全修飾ドメイン名への解決

サーバー間での正常な通信を確保するために、ホスト・サーバーは、オペレーティング・システムのリゾルバー・ライブラリーを使用して、ホスト名を完全修飾ドメイン名 (FQDN) に解決できる必要があります。以下のいずれかの条件が満たされている必要があります。

v オペレーティング・システムのホスト解決の検索順序において、DNS がローカル・ファイルに先行していること。この設定を構成するには、オペレーティング・システムの資料を参照してください。

v ホスト・ファイルでは、TADDM サーバーの FQDN が短縮名に先行していること。

いずれの条件も満たせない場合は、collation.properties ファイルのcom.collation.serverID プロパティーを TADDM サーバーの IP またはホスト名に設定できます。また、同期サーバーまたはエンタープライズ・サーバー上で稼働しているデータ管理ポータルの「ドメインの管理」の「ドメイン・ホスト名(Domain Host Name)」の ServerID が同じ値に設定されていることを確認してください。

一時ポート

TADDM 通信には、一時ポートの使用が含まれます。このポートは一時的なものであり、オペレーティング・システムに固有です。各オペレーティング・システムには、定義済みのポート番号の範囲があり、その中から特定のポートがランダムに選択されます。これらのポートは TADDM では定義されていません。ポートの範囲、必要な構成および詳細情報については、ご使用のオペレーティング・システムの資料を参照してください。

ファイアウォールの構成TADDM 通信を確立するには、必要なファイアウォールを構成する必要があります。このタスクの詳細は、ドメイン・サーバー、ストリーミング・サーバー、同期サーバーのいずれのデプロイメント環境が構成されているかによって異なります。


ファイアウォール構成情報を、以下の各表に示します。これらの表には、通信の方向が記載されています。ターゲット・マシンでは、発信接続のソースとして、また着信接続の宛先として、ファイアウォールで、ターゲット・サービス・ポートが開かれている必要があります。ソース・マシンでは、発信接続の宛先として、また着信接続のソースとして、ファイアウォールで、ターゲット・サービス・ポートが開かれている必要があります。

重要: 下位のクライアントから上位のサービスを使用できることも必要です。例えば、サーバー間接続では、パブリック・サービスも開かれている必要があります。

表に示されている方向がループバックであるときは、このインターフェースですべての通信を開く必要があります。いずれかのデフォルトのポート構成を変更した場合は、現在の環境の構成に適したポートを開く必要があります。

ドメイン・サーバーのデプロイメント環境におけるファイアウォールの構成通信用に特定のポートを開くために、ドメイン・サーバーのデプロイメント環境でファイアウォールを構成する必要があります。

以下の図は、ドメイン・サーバーのデプロイメント環境における TADDM 通信を示しています。

接続サービス:

ドメイン・サーバーのデプロイメント環境では、パブリック接続サービス、サーバー間接続サービス、ローカル接続サービスを構成することができます。

パブリック接続サービス

ドメイン・サーバーのパブリック接続サービスのデフォルトのホスト設定を以下の表に示します。

表 5. ドメイン・サーバーのパブリック接続サービスのデフォルトのホスト設定


パブリック・サービス・ホスト


データ$%ポータル

ディスカバリー$%コンソール

API

クライアント

ドメイン・サーバーアンカー

ゲートウェイ

データベース

図 1. ドメイン・サーバーのデプロイメント環境における TADDM 通信

管理 51

ドメイン・サーバーのパブリック接続サービスのデフォルトのポート設定を以下の表に示します。

表 6. ドメイン・サーバーのパブリック接続サービスのデフォルトのポート設定

名前構成プロパティープロトコル

デフォルト・ポート

API サーバー・ポート com.ibm.cdb.service.ApiServer.port TCP 9530

セキュア API サーバー・ポート

com.ibm.cdb.service.SecureApiServer.secure.port TCP 9531

HTTP ポート (SSL を使用しない)

com.ibm.cdb.service.web.port TCP 9430

HTTPS ポート (SSL を使用する)

com.ibm.cdb.service.web.secure.port TCP 9431

GUI サーバー通信ポート

com.ibm.cdb.service.ClientProxyServer.port TCP 9435

GUI サーバー SSL 通信ポート

com.ibm.cdb.service.SecureClientProxyServer.secure.port TCP 9434

パブリック・サービス・レジストリー・ポート

com.ibm.cdb.service.registry.public.port TCP 9433

ローカル接続サービス

ローカル・サービス・ポートは、明示的には設定されません。すべてのポートは、ローカル・サービス用に定義されているインターフェース上で開かれている必要があります。デフォルトのインターフェースはループバックです。

ドメイン・サーバーのローカル接続サービスのデフォルトのホスト設定を以下の表に示します。

表 7. ドメイン・サーバーのローカル接続サービスのデフォルトのホスト設定


ローカル・サービス・ホスト


ドメイン・サーバー・デプロイメントでの通信の構成:

ドメイン・サーバー・デプロイメントで正常な通信を確立するには、パブリック接続サービスとローカル接続サービスを構成します。

以下の表に、ドメイン・サーバー・デプロイメントで接続できるエレメントと、通信を正常に行うために開く必要があるポートを示します。

データベース・サーバーとドメイン・サーバーの間の通信

表 8. データベース・サーバーとドメイン・サーバーの間の通信。

エレメント A ポート方向エレメント B 構成プロパティー

データベース・サーバー

5000 ドメイン・サーバー


ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーの間の通信

表 9. ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーの間の通信。


ディスカバリー管理ポータル

9433 ドメイン・サーバー - パブリック・サービス・レジストリー

com.ibm.cdb.service.registry.public.port

9435 ドメイン・サーバー -ClientProxyServer

com.ibm.cdb.service.ClientProxyServer.port

9434 ドメイン・サーバー -SecureClientProxyServer

com.ibm.cdb.service.SecureClientProxyServer.secure.port

API クライアント



9530 ドメイン・サーバー - API サーバー

com.ibm.cdb.service.ApiServer.port

9531 ドメイン・サーバー - セキュアAPI サーバー

com.ibm.cdb.service.SecureApiServer.secure.port

Web ポータル・クライアントおよびデータ管理ポータル・クライアント

9430 ドメイン・サーバー - Web com.ibm.cdb.service.web.port

9431 ドメイン・サーバー - セキュアWeb

com.ibm.cdb.service.web.secure.port

アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信

表 10. アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信。


アンカー (SSHモード) - SSH

22 ドメイン・サーバー (ssh モード)

アンカー (ダイレクト・モード) - SSH

ドメイン・サーバー (direct モード)

アンカー (SSHモード) - SSHトンネル転送


アンカー(direct モード)- direct


ゲートウェイ -SSH


ローカル通信

管理 53

表 11. ドメイン・サーバーのローカル接続の通信構成

ローカル通信方向構成プロパティー

ドメイン・サーバー - ローカル・サービス・レジストリー

com.ibm.cdb.local.hostname

ドメイン・サーバー - ローカル・サービス

ドメイン・サーバー - 127.0.0.1

ストリーミング・サーバーのデプロイメント環境におけるファイアウォールの構成通信用に特定のポートを開くために、ストリーミング・サーバーのデプロイメント環境でファイアウォールを構成する必要があります。

以下の図は、ストリーミング・サーバーのデプロイメント環境における TADDM通信を示しています。

接続サービス:

ストリーミング・サーバーのデプロイメント環境では、パブリック接続サービス、サーバー間接続サービス、ローカル接続サービスを構成することができます。

重要: このセクションで後述するプロパティーのデフォルト・ポートは、collation.properties ファイルにリストされたプロパティーにのみ適用されます。collation.properties ファイルでプロパティーがコーディングされていない場合、またはコメント化されている場合は、ランダム・ポートがデフォルト設定されます。始動を成功させるために、特に、

API1

2

図 2. ストリーミング・サーバー・デプロイメントでの TADDM 通信


com.ibm.cdb.service.RegistriesURLProvider.port プロパティーがcollation.properties ファイルにリストされていることを確認してください。


1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのホスト設定を以下の表に示します。

表 12. 1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのホスト設定




1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのポート設定を以下の表に示します。

表 13. 1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのパブリック接続サービスのデフォルトのポート設定








HTTPS ポート (SSLを使用する)


GUI サーバー通信ポート

com.ibm.cdb.service.ClientProxyServer.port TCP 9435





サーバー間接続サービス

1 次ストレージ・サーバー、および 2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのホスト設定を以下の表に示します。

表 14. 1 次ストレージ・サーバー、および 2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのホスト設定


サーバー間サービス・ホスト


管理 55

1 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定を以下の表に示します。

表 15. 1 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定

名前構成プロパティープロトコルデフォルト・ポート

TopologyManager ポート com.ibm.cdb.service.TopologyManager.port TCP 9550

SecurityManager ポート com.ibm.cdb.service.SecurityManager.port TCP 9540

RegistriesURLProvider ポート com.ibm.cdb.service.RegistriesURLProvider.port TCP 9560

サーバー間サービス・レジストリー・ポート

com.ibm.cdb.service.registry.interserver.port TCP 4160

2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定を以下の表に示します。

表 16. 2 次ストレージ・サーバーのサーバー間接続サービスのデフォルトのポート設定

名前構成プロパティープロトコルデフォルト・ポート







1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのローカル接続サービスのデフォルトのホスト設定を以下の表に示します。

表 17. 1 次ストレージ・サーバー、2 次ストレージ・サーバー、およびディスカバリー・サーバーのローカル接続サービスのデフォルトのホスト設定


ローカル接続領域のサービス・ホスト


ストリーミング・サーバー・デプロイメントでの通信の構成:

ストリーミング・サーバー・デプロイメントで正常な通信を確立するには、パブリック接続サービス、サーバー間接続サービス、およびローカル接続サービスを構成します。

以下の表に、ストリーミング・サーバー・デプロイメントで接続できるエレメントと、通信を正常に行うために開く必要があるポートを示します。

サーバー間通信


表 18. ストリーミング・サーバー・デプロイメントでのサーバー間接続の通信構成。

エレメント A ポート方向エレメント B 構成プロパティーTLS サポート


1 次ストレージ・サーバー

9433 1 次ストレージ・サーバー


はい

4160 1 次ストレージ・サーバー - サーバー間サービス・レジストリー

com.ibm.cdb.service.registry.interserver.port

いいえ

9560 1 次ストレージ・サーバー - RegistriesURLProvider

com.ibm.cdb.service.RegistriesURLProvider.port

はい

9540 1 次ストレージ・サーバー -SecurityManager

com.ibm.cdb.service.SecurityManager.port

はい

9550 1 次ストレージ・サーバー -TopologyManager

com.ibm.cdb.service.TopologyManager.port

はい

9430 1 次ストレージ・サーバー - Web

com.ibm.cdb.service.web.port

いいえ





いいえ

9560 2 次ストレージ・サーバー - レジストリーURL プロバイダー


はい



はい





いいえ

9560 1 次ストレージ・サーバー - RegistriesURLProvider


はい

9540 1 次ストレージ・サーバー -SecurityManager

com.ibm.cdb.service.SecurityManager.port

はい



はい



いいえ

管理 57

表 18. ストリーミング・サーバー・デプロイメントでのサーバー間接続の通信構成。 (続き)




いいえ

ディスカバリー管理ポータル、API クライアントと Web ポータルおよびデータ管理ポータルのクライアント、ならびに TADDM サーバーの間の通信

表 19. ディスカバリー管理ポータル、API クライアントと Web ポータルおよびデータ管理ポータルのクライアント、ならびに TADDM サーバーの間の通信。



9433 ディスカバリー・サーバー - パブリック・サービス・レジストリー


はい

9435 ディスカバリー・サーバー -ClientProxyServer


いいえ

9434 ディスカバリー・サーバー -SecureClientProxyServer


はい


表 19. ディスカバリー管理ポータル、API クライアントと Web ポータルおよびデータ管理ポータルのクライアント、ならびに TADDM サーバーの間の通信。 (続き)


API クライアント 9433 v ディスカバリー・サーバー - パブリック・サービス・レジストリー

v 1 次ストレージ・サーバー - パブリック・サービス・レジストリー

v 2 次ストレージ・サーバー - パブリック・サービス・レジストリー


はい

9530 v ディスカバリー・サーバー - APIサーバー

v 1 次ストレージ・サーバー - APIサーバー

v 2 次ストレージ・サーバー - APIサーバー


いいえ

9531 v ディスカバリー・サーバー - セキュア API サーバー

v 1 次ストレージ・サーバー - セキュア API サーバー

v 2 次ストレージ・サーバー - セキュア API サーバー


はい

管理 59

表 19. ディスカバリー管理ポータル、API クライアントと Web ポータルおよびデータ管理ポータルのクライアント、ならびに TADDM サーバーの間の通信。 (続き)



9430 v ディスカバリー・サーバー - Web

v 1 次ストレージ・サーバー - Web

v 2 次ストレージ・サーバー - Web


いいえ

9431 v ディスカバリー・サーバー - セキュア Web

v 1 次ストレージ・サーバー - セキュア Web

v 2 次ストレージ・サーバー - セキュア Web


はい

アンカーとゲートウェイ、およびディスカバリー・サーバーの間の通信

表 20. アンカーとゲートウェイ、およびディスカバリー・サーバーの間の通信。



22 ディスカバリー・サーバー (SSHモード)


ディスカバリー・サーバー (ダイレクト・モード)


8497 ディスカバリー・サーバー (SSHモード)


ディスカバリー・サーバー (ダイレクト・モード)


22 ディスカバリー・サーバー

ローカル通信

表 21. ストリーミング・サーバー・デプロイメントでのローカル接続の通信構成。




表 21. ストリーミング・サーバー・デプロイメントでのローカル接続の通信構成。 (続き)


ディスカバリー・サーバー - ローカル・サービス・レジストリー


ディスカバリー・サーバー - ローカル・サービス

ディスカバリー・サーバー - 127.0.0.1


1 次ストレージ・サーバー - ローカル・サービス・レジストリー


1 次ストレージ・サーバー - ローカル・サービス

1 次ストレージ・サーバー - 127.0.0.1


2 次ストレージ・サーバー - ローカル・サービス・レジストリー


2 次ストレージ・サーバー - ローカル・サービス

2 次ストレージ・サーバー - 127.0.0.1

同期サーバーのデプロイメント環境におけるファイアウォールの構成通信用に特定のポートを開くために、同期サーバーのデプロイメント環境でファイアウォールを構成する必要があります。

以下の図は、同期サーバーのデプロイメント環境における TADDM 通信を示しています。

接続サービスの構成:

同期サーバーのデプロイメント環境では、パブリック接続サービス、サーバー間接続サービス、ローカル接続サービスを構成することができます。

重要: このセクションで後述するプロパティーのデフォルト・ポートは、collation.properties ファイルにリストされたプロパティーにのみ適用されます。


ディスカバリー$%コンソール

API

クライアント


ゲートウェイ


API

クライアント

<=サーバー

データベース

アンカー

データベース

図 3. 同期サーバー・デプロイメントでの TADDM 通信

管理 61

collation.properties ファイルでプロパティーがコーディングされていない場合、またはコメント化されている場合は、ランダム・ポートがデフォルト設定されます。始動を成功させるために、特に、com.ibm.cdb.service.RegistriesURLProvider.port プロパティーがcollation.properties ファイルにリストされていることを確認してください。


ドメイン・サーバー、および同期サーバーのパブリック接続サービスのデフォルトのホスト設定を以下の表に示します。

表 22. ドメイン・サーバー、および同期サーバーのパブリック接続サービスのデフォルトのホスト設定




ドメイン・サーバーのパブリック接続サービスのデフォルトのポート設定を以下の表に示します。

表 23. ドメイン・サーバーのパブリック接続サービスのデフォルトのホスト設定








HTTPS ポート (SSL を使用する)


GUI サーバー通信ポート com.ibm.cdb.service.ClientProxyServer.port TCP 9435





同期サーバーのパブリック接続サービスのデフォルトのポート設定を以下の表に示します。

表 24. 同期サーバーのパブリック接続サービスのデフォルトのポート設定



API サーバー・ポート

com.ibm.cdb.service.ApiServer.port TCP 9530



HTTP ポート (SSLを使用しない)



表 24. 同期サーバーのパブリック接続サービスのデフォルトのポート設定 (続き)



HTTPS ポート (SSLを使用する)




サーバー間接続サービス

ドメイン・サーバー、および同期サーバーのサーバー間接続サービスのデフォルトのホスト設定を以下の表に示します。

表 25. ドメイン・サーバー、および同期サーバーのサーバー間接続サービスのデフォルトのホスト設定


サーバー間サービス・ホスト


ドメイン・サーバーのサーバー間接続サービスのデフォルトのポート設定を以下の表に示します。

表 26. ドメイン・サーバーのサーバー間接続サービスのデフォルトのポート設定




SecurityManager ポート com.ibm.cdb.service.SecurityManager.port TCP 9540

RegistriesURLProvider ポート

com.ibm.cdb.service.RegistriesURLProvider.port TCP 9560



同期サーバーのサーバー間接続サービスのデフォルトのポート設定を以下の表に示します。

表 27. 同期サーバーのサーバー間接続サービスのデフォルトのポート設定




EnterpriseSecurityManager ポート

com.ibm.cdb.service.EnterpriseSecurityManager.port TCP 9570



管理 63



ドメイン・サーバー、および同期サーバーのローカル接続サービスのデフォルトのホスト設定を以下の表に示します。

表 28. ドメイン・サーバー、および同期サーバーのローカル接続サービスのデフォルトのホスト設定


ローカル・サービス・ホスト


同期サーバー・デプロイメントでの通信の構成:

同期サーバー・デプロイメントで正常な通信を確立するには、パブリック接続サービス、サーバー間接続サービス、およびローカル接続サービスを構成します。

以下の表に、同期サーバー・デプロイメントで接続できるエレメントと、通信を正常に行うために開く必要があるポートを示します。

サーバー間通信

表 29. 同期サーバー・デプロイメントでのサーバー間接続の通信構成。

エレメントA ポート方向エレメント B 構成プロパティー


同期サーバー

4160 同期サーバー - サーバー間サービス・レジストリー


9560 同期サーバー -RegistriesURLProvider


9570 同期サーバー -EnterpriseSecurityManager

com.ibm.cdb.service.EnterpriseSecurityManager.port


同期サーバー


表 29. 同期サーバー・デプロイメントでのサーバー間接続の通信構成。 (続き)

エレメントA ポート方向エレメント B 構成プロパティー

ドメイン・サーバー - サーバー間サービス・レジストリー

4160 同期サーバー com.ibm.cdb.service.registry.interserver.port

ドメイン・サーバー - レジストリーURL プロバイダー

9560 com.ibm.cdb.service.RegistriesURLProvider.port

ドメイン・サーバー - セキュリティー・マネージャー

9540 com.ibm.cdb.service.SecurityManager.port

ドメイン・サーバー - トポロジー・マネージャー

9550 com.ibm.cdb.service.TopologyManager.port




5000 同期サーバー

ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーおよび同期サーバーの間の通信

表 30. ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーおよび同期サーバーの間の通信。





9435 ドメイン・サーバー -ClientProxyServer


9434 ドメイン・サーバー -SecureClientProxyServer


管理 65

表 30. ディスカバリー管理ポータル、API クライアント、Web ポータル・クライアントおよびデータ管理ポータル・クライアントと、ドメイン・サーバーおよび同期サーバーの間の通信。 (続き)


API クライアント

9433 v ドメイン・サーバー - パブリック・サービス・レジストリー

v 同期サーバー - パブリック・サービス・レジストリー


9530 v ドメイン・サーバー - APIサーバー

v 同期サーバー - API サーバー


9531 v ドメイン・サーバー - セキュア API サーバー

v 同期サーバー - セキュアAPI サーバー



9430 v ドメイン・サーバー - Web

v 同期サーバー - Web


9431 v ドメイン・サーバー - セキュア Web

v 同期サーバー - セキュアWeb


アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信

表 31. アンカーおよびゲートウェイと、ドメイン・サーバーの間の通信。












ローカル通信

表 32. 同期サーバー・デプロイメントでのローカル接続の通信構成。




表 32. 同期サーバー・デプロイメントでのローカル接続の通信構成。 (続き)


ドメイン・サーバー - ローカル・サービス・レジストリー


ドメイン・サーバー - ローカル・サービス

ドメイン・サーバー - 127.0.0.1

同期サーバー

同期サーバー - ローカル・サービス・レジストリー


同期サーバー - ローカル・サービス

同期サーバー - 127.0.0.1

TADDM サーバー・プロパティーのリファレンスcollation.properties ファイルには、TADDM サーバーのプロパティーが含まれています。これらのプロパティーの一部は、編集することができます。

collation.properties ファイルは、 $COLLATION_HOME/etc ディレクトリーにあります。このファイルには、各プロパティーに関するコメントが含まれます。

collation.properties ファイルを更新した場合は、ファイルを保存し、サーバーを再始動して変更を有効にします。

スコープ付きプロパティーとスコープなしプロパティー

collation.properties ファイルには、スコープ付きプロパティーとスコープなしプロパティーの 2 種類のプロパティーが記述されています。

スコープ付きプロパティーIP アドレスまたはスコープ・セット名のいずれかを追加できるプロパティー。 IP アドレスまたはスコープ・セット名を追加すると、プロパティーは、ディスカバーされるホストに依存するようになります。使用できるスコープ・セット名は、スペース、アポストロフィ (')、ピリオド (.)、およびスラッシュ (/) を含まないものに限られます。

スコープなしプロパティーあるオブジェクトに固有となるように制限することができないプロパティー。

例えば、以下のプロパティーはスコープなしプロパティーです。

v com.collation.log.filesize

v com.collation.discover.agent.command.lsof.Linux

ただし、com.collation.discover.agent.command.lsof.Linux プロパティーは、以下の例のように IP アドレスやスコープ・セット名をプロパティーに付加することでスコープ付きプロパティーにすることができます。

v IP アドレス 129.42.56.212 を付加した例:

com.collation.discover.agent.command.lsof.Linux.129.42.56.212=sudo lsof

管理 67

v 「scope1」という名前のスコープ・セットを付加した例:

com.collation.discover.agent.command.lsof.Linux.scope1=sudo lsof

変更してはならないプロパティーcollation.properties ファイル内の一部のプロパティーを変更すると、システムが作動不能になる可能性があります。

以下のプロパティーは変更しないでください。

com.collation.version製品のバージョンを示します。

com.collation.branchコードのブランチを示します。

com.collation.buildnumberビルド番号を示します。この番号は、ビルド・プロセスで設定されます。

com.collation.oalbuildnumber別のビルド・プロセスのビルド番号を示します。

com.collation.SshWeirdReauthErrorList=Permission deniedこのプロパティーの値は Permission denied でなければなりません。

Windows システムでは、有効なログイン操作が不規則に拒否されることがあるため、このプロパティーが必要になります。以前、ディスカバリーの実行時に機能したユーザー名とパスワードのペアを試行できます。

アクセス資格情報のキャッシュ・プロパティーこれらのプロパティーは、アクセス資格情報のキャッシュに適用されます。

com.ibm.cdb.security.auth.cache.disabled=falseデフォルト値は false です。

このプロパティーは、資格情報のキャッシュを無効にするかどうかを決定します。

このプロパティーは、スコープ付きのプロファイルされたプロパティーです。 IP アドレス、スコープ・セットの名前、またはプロファイル名を追加できます。ディスカバリー管理コンソールのプロファイル構成で設定することもできます。

com.ibm.cdb.security.auth.cache.fallback.failed=trueデフォルト値は true です。

このプロパティーは、キャッシュに有効な資格情報が入っていても、取得時に検証できない場合に、フォールバックをオンにします。フォールバックが有効になっていて、キャッシュに入っている資格情報が無効な場合、キャッシュは一致が見つかるまで、すべての使用可能なアクセス・エントリー・タイプを順に処理します。

このプロパティーは、スコープ付きのプロファイルされたプロパティーです。 IP アドレス、スコープ・セットの名前、またはプロファイル名を追加できます。

以下の項目は、collation.properties ファイル内で見つかる項目の例です。


com.ibm.cdb.security.auth.cache.fallback.failed=falsecom.ibm.cdb.security.auth.cache.fallback.failed.10.160.160.11=truecom.ibm.cdb.security.auth.cache.fallback.failed.ScopeA=truecom.ibm.cdb.security.auth.cache.fallback.failed.GroupA=truecom.ibm.cdb.security.auth.cache.fallback.failed.Level_2_Discovery=false

このプロパティーは、ディスカバリー管理コンソールの「プラットフォーム・プロパティー」タブのプロファイル構成でも設定できます。

com.ibm.cdb.security.auth.cache.fallback.invalid=trueデフォルト値は true です。

このプロパティーは、キャッシュから読み取られた項目に無効な試行が含まれている場合 (最後のアクセスが失敗し、有効な資格情報がなかった場合)にフォールバックをオンにします。フォールバックが有効になっている場合、キャッシュは一致が見つかるまで、すべての使用可能なアクセス・エントリー・タイプを順に処理します。

このプロパティーはスコープ付きのプロファイルされたプロパティーであり、IP アドレス、スコープ・セットの名前、またはプロファイル名を付加できます。

以下の項目は、collation.properties ファイル内で見つかる項目の例です。

com.ibm.cdb.security.auth.cache.fallback.invalid=falsecom.ibm.cdb.security.auth.cache.fallback.invalid.10.160.160.11=truecom.ibm.cdb.security.auth.cache.fallback.invalid.ScopeA=truecom.ibm.cdb.security.auth.cache.fallback.invalid.GroupA=truecom.ibm.cdb.security.auth.cache.fallback.invalid.Level_2_Discovery=false

このプロパティーは、ディスカバリー管理コンソールの「プラットフォーム・プロパティー」タブのプロファイル構成でも設定できます。

Fix Pack 5 com.ibm.cdb.security.auth.cache.itm.disabled=trueデフォルト値は true です。

このプロパティーは、OSLC ディスカバリーに対して資格情報のキャッシュを無効にするかどうかを決定します。


関連概念:

16 ページの『最後の正常な資格情報キャッシング』TADDM は、有効な最後のアクセス資格情報をキャッシュに入れることができます。これらの資格情報は、次の (レベル 2 またはスクリプト・ベースの) ディスカバリーで再利用できます。

API ポート・プロパティーこれらのプロパティーは、API ポートに適用されます。

com.ibm.cdb.service.ApiServer.port=9530デフォルト値は 9530 です。値は整数でなければなりません。

管理 69

このプロパティーは、API サーバーが非 SSL 要求を listen するポートを指定します。この値には、サーバーで使用可能なポートのいずれかを設定できます。接続に API を使用するクライアントでは、非 SSL 接続用にこのポートを指定する必要があります。

com.ibm.cdb.service.SecureApiServer.secure.port=9531デフォルト値は 9531 です。値は整数でなければなりません。

このプロパティーは、API サーバーが SSL 要求を listen するポートを指定します。この値には、サーバーで使用可能なポートのいずれかを設定できます。接続に API を使用するクライアントでは、SSL 接続用にこのポートを指定する必要があります。

クリーンアップ・エージェントのプロパティークリーンアップ・エージェントは、孤立した別名や構成アイテムを削除したり、テーブル内の欠落行を修正したりします。ほとんどのクリーンアップ・エージェントは、collation.properties ファイルで定義されたプロパティーを読み取ります。

AliasesCleanupAgent

このエージェントは、CI 命名属性と一致しない別名を ALIASES テーブルから削除します。また、対応する CI がない別名と行を PERSOBJ テーブルから削除します。このエージェントは、collation.properties ファイルから以下のプロパティーを読み取ります。

Fix Pack 2

com.ibm.cdb.topomgr.topobuilder.deleteAliasesWithoutMaster

デフォルト値は true です。

このプロパティーは、対応するマスター別名がない別名を ALIASES テーブルから削除するかどうかを指定します。デフォルトでは、削除が有効になっています。

com.ibm.cdb.topomgr.topobuilder.max.row.fetchデフォルト値は 1000 です。

このプロパティーは、ALIASES テーブルから別名を取り出すために使用されるバッチ・サイズを構成します。

このプロパティーを -1 に設定すると、エージェントは別名を検査しません。

com.ibm.cdb.topomgr.topobuilder.max.row.deleteデフォルト値は 5000 です。

このプロパティーは、別名を削除するために使用されるバッチ・サイズを構成します。

このプロパティーを -1 に設定すると、エージェントは別名を削除せず、破損している別名の報告のみを行います。

com.ibm.cdb.topomgr.topobuilder.agents.AliasesCleanupAgent.maxNumberOfMastersToScan

デフォルト値は 1000 です。

このプロパティーは、エージェントの 1 回の実行中に別名の検証を必要とする CI の数を構成します。


com.ibm.cdb.topomgr.topobuilder.cleanupOrphanedAliasesAndPersobjデフォルト値は true です。この場合、エージェントはクリーンアップを実行します。

このプロパティーは、ALIASES テーブル内の別名と PERSOBJ テーブル内の GUID のうち、対応する CI がないものについて、クリーンアップの有効と無効を切り替えます。

com.ibm.cdb.topomgr.topobuilder.DelayToRemoveAliasesデフォルト値は 12 (時間) です。この場合、12 時間以上経過した孤立エイリアスは、エージェントによって削除されます。

このプロパティーは、対応する CI がない別名がエージェントによって削除されるまでの時間を、時間単位で定義します。新しい別名で、CI の保管が完了していないために対応する CI が存在しない可能性がある場合、その新しい別名は保護されます。

このプロパティーは注意して使用する必要があります。このプロパティーには、小さな値を設定しないでください。

AliasesJnTableCleanupAgent

このエージェントは、ALIASES_JN テーブルから古い行を削除します。このテーブルには、ALIASES テーブルへの変更の履歴が含まれています。このテーブルは、データベース内の構成項目の潜在的なオーバー・マージの検出に使用されます。このエージェントは、collation.properties ファイルから以下のプロパティーを読み取ります。

Fix Pack 2

com.ibm.cdb.topomgr.topobuilder.agents.AliasesJnTableCleanupAgent.maxRowデフォルト値は 5000 です。このデフォルト値は変更しないでください。

このプロパティーは、エージェントによって一度に削除される最大行数を指定します。

com.ibm.cdb.topomgr.topobuilder.agents.AliasesJnTableCleanupAgent.removeOlderThanDays

デフォルト値は 30 (日) です。

このプロパティーは、指定された時刻より古い行を削除します。デフォルトでは、30 日より古い行が削除されます。

このプロパティーを 0 またはそれより小さい値に設定すると、エージェントが無効になります。

com.ibm.cdb.topomgr.topobuilder.agents.AliasesJnTableCleanupAgent.timeoutデフォルト値は 1800 (秒) です。

このプロパティーは、エージェントがタイムアウトになるまでの時間を指定します。指定された時間が古い行をすべて削除するのに十分でない場合、エージェントは次回の実行時にそれらの行の削除を試行します。

管理 71

DependencyCleanupAgent

エージェントは、休止状態の Relationship オブジェクトを削除します。このエージェントは、collation.properties ファイルから以下のプロパティーを読み取ります。

com.ibm.cdb.topomgr.topobuilder.agents.DependencyCleanupAgent.timeoutデフォルト値は 600 です (秒単位)。この時間を過ぎると、エージェントは、いくつかのオブジェクトがまだ残っていても、オブジェクトの削除を停止します。

com.ibm.cdb.topomgr.topobuilder.agents.DependencyCleanupAgent.removeOlderThanDays

デフォルト値は 90 です (日単位)。指定した値よりも古い Relationship オブジェクトは、休止状態のオブジェクトとして処理されます。

ObjectsWithoutAliasesCleanupAgent

このエージェントは、ALIASES テーブルに別名が設定されていない CI を削除します。このエージェントは、collation.properties ファイルから次のプロパティーを読み取ります。

com.ibm.cdb.topomgr.topobuilder.agents.ObjectsWithoutAliasesCleanupAgent.maxToRemove


このプロパティーは、エージェントが実行中に削除する CI の数を制限します。このプロパティーを -1 に設定すると、エージェントはクリーンアップを実行せずに終了し、「ObjectsWithoutAliasesCleanupAgent is

disabled」というメッセージが表示されます。

PersobjCleanupAgent

このエージェントは、PERSOBJ テーブル内のすべての欠落行を修正します。collation.properties ファイル内の構成は使用しません。このエージェントは、以下の例のように、修正された行数の要約を示します。

2012-08-22 18:12:21,500 TopologyBuilder [[email protected]]INFO agents.PersobjCleanupAgent - Fixed 10 rows in PERSOBJ table

StorageExtentCleanupAgent

エージェントは、休止状態の StorageExtent オブジェクトを削除します。このエージェントは、collation.properties ファイルから以下のプロパティーを読み取ります。

com.ibm.cdb.topomgr.topobuilder.agents.StorageExtentCleanupAgent.timeoutデフォルト値は 1800 です (秒単位)。この時間を過ぎると、エージェントは、いくつかのオブジェクトがまだ残っていても、オブジェクトの削除を停止します。


com.ibm.cdb.topomgr.topobuilder.agents.StorageExtentCleanupAgent.removeOlderThanDays

デフォルト値は 1 です (日単位)。親の ComputerSystems より 1 日を超えて古い StorageExtent オブジェクトは、休止状態のオブジェクトとして処理されます。

VlanInterfaceCleanupAgent

エージェントは、休止状態の VlanInterface オブジェクトを削除します。このエージェントは、collation.properties ファイルから以下のプロパティーを読み取ります。

com.ibm.cdb.topomgr.topobuilder.agents.VlanInterfaceCleanupAgent.timeoutデフォルト値は 1800 です (秒単位)。この時間を過ぎると、エージェントは、いくつかのオブジェクトがまだ残っていても、オブジェクトの削除を停止します。

com.ibm.cdb.topomgr.topobuilder.agents.VlanInterfaceCleanupAgent.removeOlderThanDays

デフォルト値は 1 です (日単位)。親の Vlan より 1 日を超えて古いVlanInterface オブジェクトは、休止状態のオブジェクトとして処理されます。

上位の特権を必要とする場合があるコマンドこれらのプロパティーは、TADDM が使用するオペレーティング・システム・コマンドを指定しますが、これらのコマンドをターゲット・システム上で実行するには、root (またはスーパーユーザー) 権限といった上位の特権を必要とする場合があります。

通常、sudo は、特権を拡大するために UNIX および Linux システムで使用されます。 sudo の代わりに以下の方法を使用することもできます。

v ターゲットの実行可能プログラムに対する setuid アクセス権限を有効にする。

v ターゲットの実行可能プログラムに関連付けられたグループに、ディスカバリー・サービス・アカウントを追加する。

v ディスカバリー・サービス・アカウントに root を使用する (推奨されません)。

各プロパティーでは、sudo をグローバルに構成して、すべてのオペレーティング・システム・ターゲット上で sudo を使用してコマンドを実行することもできますし、 sudo を特定の IP アドレスまたはスコープ・セットに制限することもできます。

重要: 特権の拡大が必要な各ターゲット・システム上で sudo を構成するときは、NOPASSWD オプションを指定する必要があります。そのようにしないと、sudoがタイムアウトになるまでディスカバリーがハングします。

com.collation.discover.agent.command.hastatus.Linux=sudo /opt/VRTSvcs/bin/hastatuscom.collation.discover.agent.command.haclus.Linux=sudo /opt/VRTSvcs/bin/hacluscom.collation.discover.agent.command.hasys.Linux=sudo /opt/VRTSvcs/bin/hasyscom.collation.discover.agent.command.hares.Linux=sudo /opt/VRTSvcs/bin/hares

管理 73

com.collation.discover.agent.command.hagrp.Linux=sudo /opt/VRTSvcs/bin/hagrpcom.collation.discover.agent.command.hatype.Linux=sudo /opt/VRTSvcs/bin/hatypecom.collation.discover.agent.command.hauser.Linux=sudo /opt/VRTSvcs/bin/hauser

v これらのプロパティーは、Veritas クラスター・コンポーネントをディスカバーするために必要です。

v sudo を使用せずにこれらのコマンドを実行するには、TADDM サービス・アカウントがターゲットの Veritas 管理グループのメンバーでなければなりません。

com.collation.discover.agent.command.vxdisk=vxdiskcom.collation.discover.agent.command.vxdg=vxdgcom.collation.discover.agent.command.vxprint=vxprintcom.collation.discover.agent.command.vxlicrep=vxlicrepcom.collation.discover.agent.command.vxupgrade=vxupgrade

v これらのプロパティーは、Veritas の標準的なストレージ情報と、その他の Veritas 固有の情報 (ディスク・グループ、Veritas ボリューム、Plex、サブディスクなど) をディスカバーします。

com.collation.platform.os.command.ps.SunOS=/usr/ucb/ps axwwcom.collation.platform.os.command.psEnv.SunOS=/usr/ucb/ps axwweeecom.collation.platform.os.command.psParent.SunOS=ps -elf -oruser,pid,ppid,commcom.collation.platform.os.command.psUsers.SunOS=/usr/ucb/ps auxw

v これらのプロパティーは、Solaris システムに関するプロセス情報をディスカバーするために必要です。

プロパティー名に SunOS バージョン番号を付加することによって、Solaris の特定のバージョンを指定することができます。例えば、次のプロパティーは Solaris 10 に固有です。

com.collation.platform.os.command.ps.SunOS5.10=sudo /usr/ucb/ps axww

com.collation.platform.os.command.ps.Linux=ps axwwcom.collation.platform.os.command.psEnv.Linux=ps axwweeecom.collation.platform.os.command.psParent.Linux=ps -ax -oruser,pid,ppid,commcom.collation.platform.os.command.psUsers.Linux=ps auxw

v これらのプロパティーは、Linux システムに関するプロセス情報をディスカバーするために必要です。

com.collation.platform.os.command.ps.AIX=ps axwwcom.collation.platform.os.command.psEnv.AIX=ps axwweeecom.collation.platform.os.command.psParent.AIX=ps -elf -oruser,pid,ppid,commcom.collation.platform.os.command.psUsers.AIX=ps auxw

v これらのプロパティーは、AIX システムに関するプロセス情報をディスカバーするために必要です。


com.collation.platform.os.command.ps.HP-UX=sh UNIX95= ps -elfx -opid,tty,state,time,argscom.collation.platform.os.command.psEnv.HP-UX=ps -eflxcom.collation.platform.os.command.psParent.HP-UX=sh UNIX95= ps -elfx -oruser,pid,ppid,commcom.collation.platform.os.command.psUsers.HP-UX=ps -efx

v これらのプロパティーは、HP-UX システムに関するプロセス情報をディスカバーするために必要です。

com.collation.discover.agent.command.lsof.Vmnix=lsofcom.collation.discover.agent.command.lsof.Linux=lsofcom.collation.discover.agent.command.lsof.SunOS.1.2.3.4=sudo lsofcom.collation.discover.agent.command.lsof.Linux.1.2.3.4=sudo lsofcom.collation.discover.agent.command.lsof.HP-UX=lsofcom.collation.discover.agent.command.lsof.AIX=lsof

v これらのプロパティーは、プロセス情報やポート情報をディスカバーするために必要です。

プロパティー名に SunOS バージョン番号を付加することによって、Solaris の特定のバージョンを指定することができます。例えば、次のプロパティーは Solaris 10 に固有です。

com.collation.discover.agent.command.lsof.SunOS5.10=sudo /usr/local/bin/lsof

com.collation.discover.agent.command.dmidecode.Linux=dmidecodecom.collation.discover.agent.command.dmidecode.Linux.1.2.3.4=sudo dmidecode

v これらのプロパティーは、Linux システムの製造元、モデル、およびシリアル番号をディスカバーするために必要です。

com.collation.discover.agent.command.vmcp.Linux=このプロパティーを使用して、z/VM® オペレーティング・システムで実行されているターゲット Linux 仮想システムでゲスト・ユーザー ID をディスカバーすることができます。

com.collation.discover.agent.command.cat.SunOS=catcom.collation.discover.agent.command.cat.SunOS.1.2.3.4=sudo cat

v このプロパティーは、Solaris システムのチェックポイント・ファイアウォールの構成情報をディスカバーするために必要です。

com.collation.discover.agent.command.interfacesettings.SunOS=sudo nddcom.collation.discover.agent.command.interfacesettings.Linux=sudo mii-toolcom.collation.discover.agent.command.interfacesettings.SunOS.1.2.3.4=sudo nddcom.collation.discover.agent.command.interfacesettings.Linux.1.2.3.5=sudomii-toolcom.collation.discover.agent.command.interfacesettings.HP-UX=lanadmincom.collation.discover.agent.command.interfacesettings.AIX=netstat

v これらのプロパティーは、高度なネットワーク・インターフェース情報(インターフェースの速度など) をディスカバーするために必要です。

com.collation.discover.agent.command.adb.HP-UX=adbcom.collation.discover.agent.command.adb.HP-UX.1.2.3.4=sudo adb

管理 75

v このプロパティーは、HP システムに関するプロセッサー情報をディスカバーするために必要です。

com.collation.discover.agent.command.kmadmin.HP-UX=kmadmincom.collation.discover.agent.command.kmadmin.HP-UX.1.2.3.4=sudo/usr/sbin/kmadmin

v このプロパティーは、HP システムのカーネル・モジュールをディスカバーするために必要です。

com.collation.platform.os.command.partitionTableListing.SunOS=prtvtoc

v このプロパティーは、Solaris システムに関するパーティション・テーブル情報をディスカバーするために必要です。

com.collation.platform.os.command.lvm.lvdisplay.1.2.3.4=sudo lvdisplay -ccom.collation.platform.os.command.lvm.vgdisplay.1.2.3.4=sudo vgdisplay -ccom.collation.platform.os.command.lvm.pvdisplay.1.2.3.4=sudo pvdisplay -c

v これらのプロパティーは、ストレージ・ボリューム情報をディスカバーするために必要です。

com.collation.platform.os.command.lputil.SunOS.1.2.3.4=sudo/usr/sbin/lpfc/lputil

v このプロパティーは、Solaris システムの Emulex ファイバー・チャネルHBA 情報をディスカバーするために必要です。

com.collation.platform.os.command.crontabEntriesCommand.SunOS=crontab -lcom.collation.platform.os.command.crontabEntriesCommand.Linux=crontab -l-ucom.collation.platform.os.command.crontabEntriesCommand.AIX=crontab -lcom.collation.platform.os.command.crontabEntriesCommand.HP-UX=crontab -l

v これらのプロパティーは、crontab エントリーをディスカバーするために必要です。これらのプロパティーは、プロパティーに IP アドレスまたはスコープ・セット名を付加することにより、スコープ付きプロパティーとして指定できます。以下の例では、IP アドレスの付加を採用しています。

com.collation.platform.os.command.crontabEntriesCommand.AIX.1.2.3.4=crontab -l

com.collation.platform.os.command.filesystems.Linux=df -kTPcom.collation.platform.os.command.filesystems.SunOS=df -k | grep -v 'Nosuch file or directory' | grep -v 'Input/output error' | awk '{print $1,$2, $4, $6}'com.collation.platform.os.command.filesystems.AIX=df -k | grep -v 'No suchfile or directory' | grep -v 'Input/output error' | awk '{print $1, $2, $3,$7}com.collation.platform.os.command.filesystems.HP-UX=df -kP | grep -v 'Nosuch file or directory' | grep -v 'Input/output error' | grep -vFilesystem

v これらのプロパティーは、ファイル・システムをディスカバーするために必要です。


com.collation.platform.os.command.fileinfo.ls=sudo lscom.collation.platform.os.command.fileinfo.ls.1.2.3.4=sudo lscom.collation.platform.os.command.fileinfo.cksum=sudo cksumcom.collation.platform.os.command.fileinfo.cksum.1.2.3.4=sudo cksumcom.collation.platform.os.command.fileinfo.dd=sudo ddcom.collation.platform.os.command.fileinfo.dd.1.2.3.4=sudo dd

v これらのプロパティーは、特権ファイルを取り込むために必要です。

v 特権ファイルの取り込みが使用されるのは、ディスカバリーで必要なアプリケーション構成ファイルへの読み取りアクセス権限がディスカバリー・サービス・アカウントにない場合です。

com.collation.discover.agent.WebSphereVersionAgent.versionscript=sudoディスカバリー・ユーザーにターゲット WebSphere Application Server システムへのアクセス権限がない場合、このプロパティーを有効にすると、WebSphere versionInfo.sh ファイルにアクセスできます。

com.collation.platform.os.command.fileinfo.OnlyDirectoryRecursiveこのフラグによって、構成ファイルのディスカバー方法が変わります。デフォルト値は False です。

このフラグが True に変更された場合、このメカニズムは、あるディレクトリーの内容を再帰的にディスカバーするために find コマンドを使用しません。

このフラグが False に設定されている場合、このメカニズムは、ファイルの正確な場所が指定されていない状態で、find コマンドを使用してファイルを再帰的にディスカバーします。

コンテキスト・メニュー・サービスおよびデータ統合サービスのプロパティーこれらのプロパティーは、コンテキスト・メニュー・サービス (CMS) およびデータ統合サービス (DIS) に適用されます。

com.ibm.cdb.DisCmsIntegration.enabled=trueデフォルト値は true です。

このプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベースに登録されている TADDM データの定期的な更新のために、CMSDISAgent トポロジー・ビルダー・エージェントを使用可能にするかどうかを指定します。

com.ibm.cdb.DisCmsIntegration.dbUser=userこのプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベース用のデータベース・ユーザー ID を指定します。

com.ibm.cdb.DisCmsIntegration.dbPassword=passwordこのプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベース・ユーザー用のパスワードを指定します。

com.ibm.cdb.DisCmsIntegration.dbUrl=urlこのプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベース用のデータベース URL を指定します。

管理 77

com.ibm.cdb.DisCmsIntegration.dbDriver=driverこのプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービス用のデータベース・ドライバーを指定します。

com.ibm.cdb.DisCmsIntegration.changehistory.days_previous=30デフォルト値は 30 です。

このプロパティーは、コンテキスト・メニュー・サービスおよびデータ統合サービス用の変更レポートに表示される変更履歴の日数を指定します。

データベース・プロパティーこれらのプロパティーは、TADDM データベースに適用されます。

com.collation.db.password=passwordこのプロパティーは、データベース・ユーザー用のデータベース・パスワード (TADDM サーバーに格納されている) を指定します。

com.collation.db.archive.password=passwordこのプロパティーは、データベース・アーカイブ・ユーザー用のデータベース・パスワード (TADDM サーバーに格納されている) を指定します。

com.ibm.cdb.db.max.retriesこのプロパティーは、データベースへの接続を確立するための再試行回数を指定します。

com.ibm.cdb.db.timeoutこのプロパティーは、再試行間のスリープ時間 (ミリ秒単位) を指定します。

com.ibm.cdb.db.connection.ssl.enable=falseこのプロパティーは、データベース・ユーザー用のデータベースに SSL モードで接続を確立するかどうかを指定します。

デフォルト値は false です。

com.ibm.cdb.db.connection.ssl.truststore.file=filenameこのプロパティーは、データベース・ユーザー用のデータベースに SSL 接続するために使用されるトラストストア・ファイルを指定します。トラストストア・ファイルは、$COLLATION_HOME/etc/ ディレクトリーに配置されている必要があります。

com.ibm.cdb.db.connection.ssl.truststore.password=passwordこのプロパティーは、データベース・ユーザー用のデータベースに SSL 接続するために使用されるトラストストア・パスワードを指定します。

com.ibm.cdb.db.archive.connection.ssl.enable=falseこのプロパティーは、アーカイブ・データベース・ユーザー用のデータベースに SSL モードで接続を確立するかどうかを指定します。


com.ibm.cdb.db.archive.connection.ssl.truststore.file=filenameこのプロパティーは、アーカイブ・データベース・ユーザー用のデータベースに SSL 接続するために使用されるトラストストア・ファイルを指定します。トラストストア・ファイルは、$COLLATION_HOME/etc/ ディレクトリーに配置されている必要があります。


com.ibm.cdb.db.archive.connection.ssl.truststore.password=passwordこのプロパティーは、アーカイブ・データベース・ユーザー用のデータベースに SSL 接続するために使用されるトラストストア・パスワードを指定します。

collation.properties ファイル内のデータベース・パスワードを暗号化するには、以下のようにします。

1. データベース・ユーザーを編集するか、平文によってユーザー・パスワードをアーカイブするか、またはその両方を行います。


3. encryptprops.sh ファイルまたは encryptprops.bat ファイル($COLLATION_HOME/bin ディレクトリーにある) のいずれかを実行します。このスクリプトにより、パスワードが暗号化されます。


ディスカバリー・プロパティーディスカバリー・プロパティーは、ディスカバリー全般に適用されます。特定のセンサーに影響を与える TADDM サーバー・プロパティーについては、それぞれのセンサーに関する TADDM の「センサー解説書」を参照してください。

Fix Pack 4

com.discover.anchor.maxChannelNumber

このプロパティーは、TADDM サーバーとアンカーの間の SSH セッションで同時に開かれるチャネルの最大数を指定します。開かれたチャネルの数が多すぎると、そのアンカーでのディスカバリーがハングする可能性があり、そのスコープに含まれるセンサーがタイムアウトになる可能性があります。その場合は、このプロパティーを使用して、開かれるチャネルの数を制御してください。


Fix Pack 4

com.collation.platform.os.copyToLocal.preferScpCommand

このプロパティーは、リモート・ホスト (通常はディスカバリー・ターゲット) から TADDM サーバーにファイルをコピーする際に、外部の scp コマンドを使用するかどうかを指定します。外部の scp コマンドは、com.collation.platform.os.scp.command プロパティーで定義されています。外部の scp コマンドを使用できるようにするには、このプロパティーを true に設定します。

このプロパティーのデフォルト値は false です。

注: このプロパティーは、鍵ベース・ログインを使用して確立された SSHセッションのみに適用されます ( 129 ページの『セキュア・シェル (SSH)を使用するディスカバリー用の構成』を参照)。ユーザー名とパスワードを使用した認証の場合は、com.collation.platform.os.copyToLocal.preferScpCommand プロパティーの値に関係なく、内部の scp コマンドが使用されます。

このプロパティーはスコープ付きプロパティーです。IP アドレスまたはスコープ・セットの名前をプロパティーに追加できます。例えば、以下のとおりです。

管理 79

com.collation.platform.os.copyToLocal.preferScpCommand.12.234.255.4=true

com.collation.platform.os.scp.commandこのプロパティーは、オペレーティング・システムの scp コマンドへのパスを指定します。これは、内部 SSH クライアントが、TADDM サーバーとリモート・ホスト (通常はディスカバリー・ターゲット) との間のファイルの送信に失敗したときに使用できます。代替コマンドを使用することもできますが、そのコマンドの構文が scp コマンドと同じでなければなりません。

値の例: /usr/local/bin/scp。

Fix Pack 3

com.collation.platform.session.ssh.winAuth

このプロパティーは、SSH セッションが使用されるときに、Windows 資格情報を使用してログインが試行されるかどうかを指定します。デフォルト値は true です。

ディスカバリー中に Windows 資格情報を使用して Windows 以外のサーバーへのログインが試行されるリスクがある場合は、値を false に設定できます。これにより、Windows Active Directory アカウントのロックアウトを防止できます。

Fix Pack 3

com.collation.platform.os.ignoreL2InterfaceDescription

このプロパティーは、コンピューター・システムのシグニチャー計算中に無視させるディスカバー対象の L2 インターフェースの記述を指定します。例えば、コンピューター・システムのシグニチャーを計算するためにMicrosoft ロード・バランサー・インターフェースを使用させない場合は、以下の値を指定します。

com.collation.platform.os.ignoreL2InterfaceDescription=Microsoft LoadBalancer Interface

このプロパティーの値は正規表現として処理されます。つまり、複数のインターフェース記述を追加でき、コンマなどの分離文字を使用する必要はありません。

Fix Pack 3

com.ibm.cdb.topomgr.topobuilder.agents.Connection

DependencyAgent2.dependencyPlaceholdersこのプロパティーは、true に設定された場合に、未検出の依存関係に対してプレースホルダー・アプリケーション・サーバーを作成します。

注: このプロパティーは、デフォルトでは collation.properties ファイルに含まれていません。そのファイルに追加する必要があります。

この値を初めて true に設定するときには、TADDM を再始動して、LogicalConnection クラスおよび SSoftwareServer クラスの拡張属性を有効にする必要があります。これらの拡張属性は、この機能が適切に動作するために必要です。

プレースホルダーについて詳しくは、 146 ページの『プレースホルダーのディスカバリーの構成』を参照してください。

com.collation.platform.session.EncodingOverRideこのプロパティーは、ディスカバリー・セッション中に使用されるエンコー


ドのタイプを指定します。これは、ターゲット・サーバーで使用されているエンコード方式が、TADDM サーバーのものとは異なる場合に特に有用です。

このプロパティーの値は、エンコードの名前 (例えば、UTF-8) です。このプロパティーは、デフォルトでは collation.properties ファイルに含まれていないため、このファイルに追加する必要があります。

このプロパティーに、スコープまたは IP アドレスを追加することもできます。例えば、以下のとおりです。

com.collation.platform.session.EncodingOverRide.37.53.105.24=UTF-8

com.collation.discover.anchor.forceDeployment=trueデフォルト値は true です。

このプロパティーは、ディスカバー対象スコープのアンカーをディスカバリー開始時にデプロイするかどうかを指定します。

この値を false に設定した場合、以下の条件のいずれかが満たされた場合のみ、アンカーがデプロイされます。

v スコープからのどの IP アドレスにも ping できない場合

v ディスカバーされたすべての IP アドレスでポート 22 にアクセスできない場合

チェーン・アンカーが存在する場合は、チェーン内のすべてのアンカーにこの条件が適用されます。チェーン内のアンカーが条件で制限されている場合、すべてのアンカーをデプロイできるようにするには、先行するアンカーが条件を満たしている必要があります。

com.collation.discover.anchor.lazyDeployment=falseデフォルト値は false です。

このプロパティーは、センサーが必要とするファイルが、アンカーのデプロイ時にコピーされるか (値が false の場合)、ファイルを必要とするセンサーが始動しようとしているときにコピーされるか (値が true の場合) を指定します。

例えば、IBM WebSphere センサーには、dist/lib/websphere ディレクトリー内に依存ファイルがあります。ディレクトリーのサイズは 130 MB です。このプロパティーの値が false である場合、依存関係データはアンカーのデプロイ時にターゲット・ホストにコピーされます。値が true の場合は、 WebSphere センサーがアンカーで実行されようとするときに、データがコピーされます。 WebSphere センサーがアンカーを通じて実行されない場合は、 130 MB がリモート・ホストに送信されません。

com.collation.discover.DefaultAgentTimeout=600000値は、ミリ秒単位で 600000 です (10 分)。

このプロパティーは、センサーのタイムアウト時間をミリ秒単位で指定します。このデフォルトのタイムアウト値は変更しないでください。代わりに、個々のセンサーのタイムアウトを指定することができます。

特定のセンサーに関してタイムアウトを指定変更するには、collation.properties ファイルに次の行を追加します。

管理 81

com.collation.discover.agent.sensorNameSensor.timeout=timeInMilliseconds

以下に例を示します。

com.collation.discover.agent.OracleSensor.timeout=1800000

com.collation.IpNetworkAssignmentAgent.defaultNetmask=ip_start-ip_end/netmask[, ...]

このプロパティーは、レベル 1 のディスカバリーでディスカバーされた IPアドレスを、生成されたサブネットにどのように割り当てるかを定義します。レベル 1 ディスカバリーは、サブネットをディスカバーしません。代わりに、レベル 2 またはレベル 3 のディスカバリーでディスカバーされた既存のサブネットと関連付けられていないすべてのインターフェースが入るIpNetwork オブジェクトが生成されます。この構成プロパティーでは、どの IpNetwork オブジェクトを作成するか、および各サブネットにノードをいくつ含めるかを定義します。(これは、レベル 2 またはレベル 3 でディスカバーされたインターフェースのうち、ディスカバーされたサブネットに何らかの理由で割り当てることができないインターフェースにも適用されます。)

このプロパティーの値は、コンマで区切られた 1 つ以上の項目を含む単一行からなります。各項目には、IPv4 のドット 10 進形式の IP アドレス範囲と、8 から 31 までの範囲の整数として指定されたサブネット・マスクが記述されます。それにより、指定範囲内でディスカバーされたインターフェースが、作成されたサブネット (サブネット・マスクによって指定されたサイズ以下) 内に置かれます。

例えば、以下の値は、異なるサブネット・マスクを持つ 2 つのサブネット・アドレス範囲を定義します。

9.0.0.0-9.127.255.255/23, 9.128.0.0-9.255.255.255/24

指定されるアドレス範囲はオーバーラップしても構いません。ディスカバーされた IP アドレスが複数の定義範囲と一致した場合、そのアドレスは、プロパティー値にリストされたサブネットのうち、最初に一致したサブネットに割り当てられます。

この構成プロパティーを作成または変更して TADDM サーバーを再始動した後は、以降のすべてのレベル 1 のディスカバリーで、定義されたサブネットが使用されます。 TADDM データベース内の既存の IpInterface オブジェクトを再割り当てするには、$COLLATION_HOME/bin ディレクトリーに移動して、以下のいずれかのコマンドを実行します。

v adjustL1Networks.sh (Linux および UNIX システム)

v adjustL1Networks.bat (Windows システム)

値が正しく指定されていない場合は、コマンド行ユーティリティーadjustL1Networks.sh (Linux および UNIX システム) またはadjustL1Networks.bat (Windows システム) を実行した場合にのみ、該当するメッセージが表示されます。それ以外の場合、メッセージは、$COLLATION_HOME/log/services ディレクトリー内の TopologyBuilder.logファイル、および $COLLATION_HOME/log/agents ディレクトリー内のIpNetworkAssignmentAgent.log ファイルに記録されます。


このスクリプトにより、レベル 1 のディスカバリーでディスカバーされたすべての IpInterface オブジェクトが、構成プロパティーに記述された適切なサブネットに再割り当てされます。生成された IpNetwork オブジェクトのうち、インターフェースを含まないものは、すべてデータベースから削除されます。スクリプト完了後、TADDM インターフェースには、オブジェクトの変更により変更されたコンポーネントがあることを示す複数の通知が表示されることがあります。これらの通知は、ウィンドウを最新表示することで消去できます。

注: このコマンドを使用する前に、TADDM サーバーが稼働していること、および現在進行中のディスカバリー操作またはバルク・ロード操作がないことを確認してください。このスクリプトは同期サーバーではサポートされていません。

com.collation.number.persist.discovery.run=30デフォルト値は 30 です。

データ管理ポータルとディスカバリー管理コンソールのディスカバリー履歴に情報が保存されるディスカバリーの数を指定します。

ストリーミング・サーバー・デプロイメントでデフォルト値を変更するには、1 次ストレージ・サーバーに新しい値を入力してください。

com.collation.platform.os.hostappdescriptorfiles.dir="path"コンピューター・システム (ホスト) のコンポーネント・アプリケーション・ディスクリプター・ファイルがデプロイされているディレクトリーの完全修飾パスを指定します。アプリケーション・ディスクリプターを使用するビジネス・アプリケーションにコンピューター・システムを追加したい場合、このプロパティーは必須です。各ホストに異なるロケーションを指定するために、このプロパティーのスコープを特定のホスト名または IP アドレスに設定することができます。以下の例は、ホストのアプリケーション・ディスクリプターのパスを指定する方法を示しています。

v Linux および UNIX システム: /home/taddm/hostappdescriptors

v Windows システム: c://taddm//hostappdescriptors

com.collation.platform.session.GatewayForceSshアンカーには依存せずに動作することをゲートウェイに対して強制するかどうかを指定します。有効な値は、true および false です。ゲートウェイとアンカーが同じシステム上にある場合、Cygwin の問題を解決するには、この値を true に設定します。値を true に設定すると、ゲートウェイとアンカーとの間のトラフィックの転送にはローカル・セッションではなく SSHセッションが使用されます。

com.collation.rediscoveryEnabled=falseデフォルト値は false です。

このプロパティーは、既にディスカバーされた構成アイテムの再ディスカバリーに適用されます。再ディスカバリー機能は、データ管理ポータルで使用可能です。

制約事項: 再ディスカバリーでは、カスタム・プロファイルからの資格情報は使用できません。グローバル・リストからの資格情報が使用されます。

管理 83

注:

ドメイン・サーバー・デプロイメントでの再ディスカバリーを使用可能にするには、ドメイン・サーバーでこの値を true に設定します。

ストリーミング・サーバー・デプロイメントでの再ディスカバリーを使用可能にするには、ディスカバリー・サーバーおよびストレージ・サーバーでこの値を true に設定します。

ストリーミング・サーバー・デプロイメントでの再ディスカバリーストリーミング・サーバー・デプロイメントで再ディスカバリーが使用される場合、構成アイテムは異なる複数のディスカバリー・サーバーによってディスカバーされますが、構成アイテムを最後にディスカバーしたディスカバリー・サーバーのみが、その構成アイテムを再ディスカバーできます。複数のディスカバリー・サーバーが存在するため、構成アイテムの再ディスカバリー情報は、それぞれのディスカバリー・サーバーによって上書きされます。

ディスカバリー・サーバーで再ディスカバリーを使用可能にすると、ディスカバーされたオブジェクトごとに、再ディスカバリーに関する追加情報が作成されます。

ストレージ・サーバーで再ディスカバリーを使用可能にすると、ディスカバーされた各オブジェクトは、再ディスカバリーに関する追加情報と共に保管されます。

再ディスカバリーが、ディスカバリー・サーバーでは使用可能であるが、ストレージ・サーバーでは使用不可になっている場合、再ディスカバリーに関する情報は、TADDM データベースで使用できません。さらに、ディスカバリー・サーバーとストレージ・サーバーの両方で同じ資格情報が使用されるようにする必要があります。

com.ibm.cdb.discover.sensor.sys.utilization.workingdir=/tmp/taddmデフォルト値は /tmp/taddm です。

このプロパティーは、ターゲット・システムで実行する IBM TivoliUtilization センサー・スクリプトのルート・パスを指定します。この値が指定されていない場合、com.ibm.cdb.taddm.script.path プロパティーで定義されたパスが使用されます。

com.ibm.cdb.locationTagTADDM サーバー上で作成される各構成アイテム (CI) のロケーション・タグ属性を指定します。CI のロケーションを識別するロケーション・タグ属性は、静的ロケーション・タグをサポートするために使用されます。このタグを指定する前に、com.ibm.cdb.locationTaggingEnabled 値を true に設定する必要があります。

com.ibm.cdb.locationTaggingEnabled=falseデフォルト値は false です。

ロケーション・タグ付け機能が有効であるかどうかを指定します。以下の場合に、このプロパティーの値を true に設定します。

v TADDM サーバー上で作成される各構成アイテム (CI) のロケーション・タグ属性 (静的ロケーション・タグ) を指定する場合。詳しくは、com.ibm.cdb.locationTag プロパティーを参照してください。


v コマンド行インターフェース (CLI) を使用して、単一ディスカバリー中に作成される構成アイテム (CI) の動的ロケーション・タグを指定する場合。動的ロケーション・タグは、既に存在しているロケーション・タグ(静的ロケーション・タグ) をオーバーライドします。

v バルク・ロード・プログラムを使用してデータをロードする際に作成される構成アイテム (CI) の動的ロケーション・タグを指定する場合。

v BIRT レポートの実行時にデータをフィルタリングして、指定されたロケーションのみに関する情報を報告するためのロケーション・タグ値を指定する場合。

v トポロジー・ビルド・プロセス中に作成される構成アイテムのロケーション・タグ値を作成する場合。

com.ibm.cdb.taddm.hostTADDM サーバー・ホスト別名を指定します。この値が指定されていない場合、システム・ホスト名が使用されます。TADDM サーバーがシステム・ホスト名を解決できない場合、または解決結果がローカル・ホストになる場合は、このプロパティーを手動で指定する必要があります。

com.ibm.cdb.taddm.script.path=/tmp/taddmデフォルト値は /tmp/taddm です。

このプロパティーは、ターゲット・システムで実行するセンサー・スクリプトのルート・パスを指定します。このロケーションで、host_alias/discovery_number/sensor_name の形式を使用してサブディレクトリー・ツリーが作成されます。host_alias 名は com.ibm.cdb.taddm.hostプロパティーから取得されます。このプロパティーが指定されていない場合、システム・ホスト名が使用されます。同じディスカバリー・サーバー上の同時ディスカバリーを区別するために、discovery_number ディレクトリーに番号が割り当てられます。このディレクトリー構造を使用して、ディスカバリー・スクリプトとディスカバリー結果が保管されます。

com.collation.discover.agent.signature.ignore.1.2.3.4=trueこのプロパティーは、シグニチャーの計算時に IP アドレスをスキップするために使用されます。

構成によっては、コンピューター・システムのシグニチャーが固有でなくなり、TADDM データベースの既存のエントリーとの調整時に問題が発生する場合があります。例えば、この問題が発生するのは、使用する仮想マシンに、有効なハードウェア・アドレスと IP アドレスを持つ仮想ネットワーク・カードがある場合です。その場合は、シグニチャーの計算を除外して、他の命名規則 (製品モデル、製造元、シリアル番号など) を使用する必要があります。

無視する IP アドレスごとに、com.collation.discover.agent.signature.ignore.1.2.3.4=true プロパティーを追加します。ここで 1.2.3.4 は、無視する IP アドレスです。

多数の IP アドレスを無視する場合は、ディスカバリー・スコープを作成します。 com.collation.discover.agent.signature.ignore.blacklist=trueプロパティーを collation.properties ファイルに追加します。ここでblacklist は、無視する IP アドレスをすべて含むディスカバリー・スコープです。

管理 85

拡張ディスカバリー・プロパティー:

拡張ディスカバリー・プロパティーは、作業項目を保管するためのバッファー容量、特定のディスカバリー・エレメントの再始動回数、または統計をログに出力する時間値を指定します。ディスカバリー・プロセスを詳細に調整する必要がない限り、これらのプロパティーを変更しないでください。

com.ibm.cdb.discover.buffers.workitem.capacity=64デフォルト値は 64 です。ただし、この値は常に、com.collation.discover.dwcount の値 (デフォルトでは 32) の 2 倍です。

このプロパティーは、ディスカバリー作業項目を保管するためのバッファー容量を指定します。これは、ディスカバリー・プロセスのメモリー所要量を制限して OutOfMemory エラーを回避するために使用されます。ディスカバリーのたびに、新規センサーが開始されます。

この値を、com.collation.discover.dwcount に指定されたディスカバリー・ワーカーの数より小さくしないでください。小さくすると、一部のディスカバリー・ワーカーがアイドル状態のままになるからです。

com.ibm.cdb.discover.buffers.workitem.maxresets=10デフォルト値は 10 です。

このプロパティーは、予期しない障害 (ディスカバリー担当の TADDMJVM の障害など) が発生した場合にセンサーが再始動できる回数を指定します。

また、ディスカバリー・プロセスのエレメントの再始動回数は、ディスカバリー再始動の回数を指定する com.ibm.cdb.discover.runrestartlimit による制限も受けます。

com.ibm.cdb.discover.buffers.seed.capacity=100デフォルト値は 100 です。

このプロパティーは、シード作業項目を保管するためのバッファー容量を指定します。これは、ディスカバリー・プロセスのメモリー所要量を制限してOutOfMemory エラーを回避するために使用されます。

com.ibm.cdb.discover.buffers.result.capacity=100デフォルト値は 100 です。

このプロパティーは、結果の作業項目を保管するためのバッファー容量を指定します。これは、ディスカバリー・プロセスのメモリー所要量を制限してOutOfMemory エラーを回避するために使用されます。結果の作業項目ごとに、新規センサーを開始できます。

値を com.ibm.cdb.discover.buffers.discovered.capacity と同じサイズに設定してください。

com.ibm.cdb.discover.buffers.result.maxresets=10デフォルト値は 10 です。

このプロパティーは、予期しない障害 (ディスカバリー担当の TADDMJVM の障害など) が発生した場合に結果の作業項目に対してディスカバリー・プロセスが新規センサーを開始できる回数を指定します。


また、ディスカバリー・プロセスのエレメントの再始動回数は、ディスカバリー再始動の回数を指定する com.ibm.cdb.discover.runrestartlimit による制限も受けます。

com.ibm.cdb.discover.buffers.discovered.capacity=100デフォルト値は 100 です。

このプロパティーは、ディスカバリー済みの作業項目を保管するためのバッファー容量を指定します。それぞれのディスカバリー済み作業項目が、データベースに保管されたディスカバリー結果を表します。

この値には、com.collation.discover.observer.topopumpcount で指定されたデータベース書き込みスレッドの数より小さい値を指定しないでください。

com.ibm.cdb.discover.buffers.statistics.interval.seconds=60デフォルト値は 60 です。値は秒単位で指定します。

このプロパティーは、ディスカバリー・バッファー統計をログに保存するための時間値を指定します。ログは、/log/services/DiscoveryState.log にあります。

com.ibm.cdb.discover.buffers.timeout.interval.seconds=600デフォルト値は 600 (10 分) です。値は秒単位で指定します。

このプロパティーは、作業項目のタイムアウトを検査するための時間値を指定します。

com.ibm.cdb.discover.runcontroller.statistics.interval.seconds=60デフォルト値は 60 です。値は秒単位で指定します。

このプロパティーは、ディスカバリー実行統計をログに保存するための時間値を指定します。ログは、/log/services/DiscoveryRunController.log にあります。

com.ibm.cdb.discover.runrestartlimit=11デフォルト値は 11 です。

このプロパティーは、未初期化ディスカバリーの失敗後に再始動できる回数を指定します。プロセスがまだディスカバリー・スコープのすべてのエレメントに対して開始されたわけではない場合、ディスカバリーは未初期化状態になります。

com.collation.discovery.oracle.tablelimit=1000デフォルト値は 1000 です。このプロパティーは、正の値のみをサポートします。

このプロパティーは、Oracle センサーによってディスカバーされるテーブルの数量を制御します。

同時実行ディスカバリー・プロパティー:

これらのプロパティーは、同時実行ディスカバリーに適用されます。

com.collation.discover.concurrent.discovery=trueデフォルト値は true です。

管理 87

このプロパティーは、同時実行ディスカバリーを使用可能にするために使用されます。

com.collation.discover.max.concurrent.discoveries=10デフォルト値は 10 です。

このプロパティーは、同時実行ディスカバリーの最大数を定義します。

非同期ディスカバリー・プロパティー:

これらのプロパティーは、非同期ディスカバリーに適用されます。

com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory=var/asddデフォルト値は var/asdd です。これは、com.collation.home ディレクトリーからの相対パスです。

このプロパティーは、非同期ディスカバリーの結果を含む、TADDM サーバー上のアーカイブ・ファイルのルート・ディレクトリーのロケーションを定義します。ロケーションは、相対パスでも絶対パスでもかまいません。相対パスは、com.collation.home ディレクトリーからの相対パスになります。

com.ibm.cdb.discover.asd.ProcessUnreachableIPs=falseデフォルト値は false です。

このプロパティーは、非同期ディスカバリーに使用される到達不能な IP アドレスの処理を使用可能にするために使用されます。これらのアドレスの処理を使用可能にするには、この値を true に設定します。

com.ibm.cdb.tarpath=tarデフォルト値は tar です。

このプロパティーは、非同期ディスカバリーでの TADDM サーバー上のtar コマンドのパスを指定します。

AIX または Linux などのオペレーティング・システムでは、このプロパティーは通常必要ありません。tar コマンドが既にインストールされ、使用可能であるためです。ただし、非同期ディスカバリー・スクリプト・パッケージを生成したり、Windows オペレーティング・システムを実行しているTADDM サーバー上のディスカバリー・アーカイブ・ファイルを処理したりするためには、サード・パーティーの tar プログラムをインストールし、そのプログラムの絶対パス名を指定する必要があります。

以下の例は、AIX オペレーティング・システムの場合、TADDM サーバー上の tar コマンドのパスを指定する方法を示しています。

com.ibm.cdb.tarpath=tar

com.ibm.cdb.targettarpath=tarデフォルト値は tar です。

このプロパティーは、非同期ディスカバリーでのターゲット・システム上のtar コマンドのパスを指定します。

AIX または Linux などのターゲット・オペレーティング・システムでは、tar コマンドが既にインストールされ、使用可能であるため、このプロパティーは通常必要ありません。ただし、Solaris オペレーティング・システムでディスカバリー・アーカイブ・ファイルを生成する場合は、ファイル名の


長さに制限があるため、gtar アーカイブ・ユーティリティーを使用し、そのユーティリティーへのパスを指定する必要があります。

以下の例は、オペレーティング・システムに応じて、ターゲット・システムの tar コマンドのパスを指定する方法を示しています。

AIX の場合com.ibm.cdb.targettarpath.AIX=tar

Solaris の場合com.ibm.cdb.targettarpath.SunOS=/usr/sfw/bin/gtar

スクリプト・ベースのディスカバリー・プロパティー:

これらのプロパティーは、スクリプト・ベースのディスカバリーに適用されます。

Fix Pack 4

com.ibm.cdb.discover.enableOutputFileSplittingProcess=true


このプロパティーは、スクリプト・ベースのディスカバリー中に作成されたメインの出力ファイルを、より小さなサイズの複数のファイルに分割するかどうかを指定します。デフォルトでは、ファイル分割が行われます。この設定により、出力ファイルのサイズが大きい場合のパフォーマンスの問題を回避できます。com.ibm.cdb.discover.numberOfLinesForOutputFileSplittingProcess プロパティーも参照してください。

Fix Pack 4

com.ibm.cdb.discover.numberOfLinesForOutputFileSplittingProcess=10000デフォルト値は 10000 です。

このプロパティーは、com.ibm.cdb.discover.enableOutputFileSplittingProcess プロパティーがtrue に設定されている場合にのみ有効になります。このプロパティーは、メインの出力ファイルを分割することによって作成される、より小さなサイズの出力ファイルで許容されるおおよその行数を指定します。正確な行数は、ファイル・フォーマットによって決まります。ファイル全体のフォーマットが正しいものとなるように、指定された行数を超えた後、意味のあるデータのまとまりの終わりに到達したときに初めてファイルが分割されます。これは、例えば値が 10000 に設定されている場合、より小さなサイズのファイルに含まれている行数が 10200 となる可能性があることを意味します。

com.ibm.cdb.taddm.asd.prefix=shデフォルト値は sh です。

このプロパティーは、ディスカバリー中に実行するスクリプトに追加するプレフィックス (例えば prefix script.sh) を指定します。このプロパティーはスコープ付きプロパティーであり、IP アドレスまたはスコープ・セットの名前を付加することができます。

com.ibm.cdb.discover.DeleteScriptDiscoveryOutputs=trueデフォルト値は true です。

管理 89

このプロパティーは、センサーによる処理のために、スクリプト・ベースのディスカバリー中に TADDMサーバーにコピーされるスクリプト出力を削除するかどうかを指定します。この出力は、トラブルシューティングに役立つことがありますが、デフォルトではディスカバリーの完了後に削除されます。このプロパティーの値を false に設定した場合、スクリプト出力は削除されません。

com.ibm.cdb.discover.DeleteRemoteBeforeScriptsRun=falseデフォルト値は false です。

このプロパティーは、TADDM が、新規ディスカバリーの実行を試行する前に、以前のディスカバリーで残されたすべての出力をリモート・ディレクトリーから削除するかどうかを指定します。

com.ibm.cdb.discover.PreferScriptDiscovery=falseデフォルト値は false です。

このプロパティーは、スクリプト・ベースのディスカバリーを使用可能にするために使用され、スクリプト・ベースのディスカバリーをサポートするセンサーのみに影響します。この値を true に設定すると、スクリプト・ベースのディスカバリーが使用可能になります。

com.ibm.cdb.discover.smallFileSizeLimit=1048576デフォルト値は 1048576 (1024*1024 - 1 MB) です。

このプロパティーは、チェックサムの使用をトリガーする、コピー操作のファイル・サイズ制限 (バイト単位) を定義します。サイズがこの制限を下回る場合、ファイルはチェックサム計算なしでコピーされます。サイズがこの制限以上の場合、ファイルは、ファイルがターゲット・ディレクトリーに存在せず、またそのチェックサムがローカル (ソース) ファイルに一致しないときにのみコピーされます。

制限を無効にするには、以下の値を使用します。

v 0 - コピー操作で常にチェックサムを使用します。

v -1 - コピー操作で常にチェックサムの使用を回避します。

IBM Tivoli Monitoring (旧方式) を使用したディスカバリーのプロパティー:

これらのプロパティーは、IBM Tivoli Monitoring (旧方式) を使用したディスカバリーに適用されます。

以前の統合方式

このセクションでは、TADDM と IBM Tivoli Monitoring の非推奨の統合方式について説明します。TADDM バージョン 7.3.0 以降、IBM Tivoli Monitoring 6.3との統合には、OSLC 自動化を使用することをお勧めします。IBM TivoliMonitoring スコープ・センサーを使用した古い統合方式は非推奨であり、将来のリリースからは削除される予定です。OSLC 自動化を使用したディスカバリー・プロセスの構成で使用するプロパティーについて詳しくは、 219 ページの『OSLC 自動化を通じた TADDM と IBM Tivoli Monitoring の統合』および 93 ページの『OSLC 自動化セッションを使用したディスカバリーのプロパティー』を参照してください。


TADDM が Tivoli Monitoring エンドポイントをディスカバーする方法に作用するプロパティー

TADDM レベル 2 およびレベル 3 ディスカバリーでは通常、以下のいずれかの方式を使用してターゲット・システムに直接接続するためのドメイン・サーバー (ドメイン・サーバー・デプロイメントまたは同期サーバー・デプロイメントの場合)またはディスカバリー・サーバー (ストリーミング・サーバー・デプロイメントの場合) が必要です。

v UNIX ベースのターゲット・システムの場合はセキュア・シェル (SSH)

v Windows システムの場合は Windows Management Instrumentation (WMI)

これらの方式を使用するには、ドメイン・サーバーまたはディスカバリー・サーバーがユーザー資格情報 (アカウントおよびパスワード) を認識していることが必要です。

IBM Tivoli Monitoring を使用したディスカバリーでは、ユーザー資格情報が利用できないターゲット・システムについて、TADDM がレベル 2 情報 (および一部のレベル 3 情報) をディスカバーすることが可能になります。センサーが TivoliMonitoring インフラストラクチャー全体について実行され、Tivoli EnterprisePortal Server の資格情報のみを検出します。IBM Tivoli Monitoring スコープ・センサーが構成および実行された後、以降のレベル 2 のディスカバリーでは、TivoliMonitoring がディスカバリーのデフォルトとして使用されます。ご使用の環境でこのデフォルト動作が好ましくない場合もあるため、TADDM には、TivoliMonitoring または直接接続 (SSH または WMI) のいずれがディスカバリーに使用されるかを制御するため、以下のサーバー・プロパティーが用意されています。これらのプロパティーは、グローバル・レベルで設定することも、特定のスコープまたはディスカバリー・プロファイルに対して設定することもできます。

com.ibm.cdb.session.allow.ITM=trueデフォルト値は true です。これは、TADDM が IBM Tivoli Monitoringを使用して Tivoli Monitoring エンドポイントをディスカバーできることを意味します。

このプロパティーは、TADDM が IBM Tivoli Monitoring を使用してTivoli Monitoring エンドポイントをディスカバーできるかどうかを指定します。

Tivoli Monitoring エンドポイントに直接接続するには、値を false に設定します。

また、このプロパティーを使用して、次の例で示すようなカスタム・ディスカバリー・スコープを指定することもできます。

com.ibm.cdb.session.allow.ITM.ip_address=false以下の例では、TADDM がディスカバリー・スコープ 10.20.30.40を使用し、Tivoli Monitoring によってモニターされていてもエンドポイントに直接接続するよう指定しています。

com.ibm.cdb.session.allow.ITM.10.20.30.40=false

com.ibm.cdb.session.prefer.ITM=trueデフォルト値は true です。これは、TADDM が IBM Tivoli Monitoringを使用して Tivoli Monitoring エンドポイントをディスカバーすることを意味します。

管理 91

このプロパティーは、TADDM が Tivoli Monitoring エンドポイントをディスカバーするための優先される方式として IBM Tivoli Monitoring を使用するかどうかを指定しますが、IBM Tivoli Monitoring を使用したエンドポイントのディスカバリーが許可されていることが前提となります。TADDM がディスカバリーに IBM Tivoli Monitoring を使用し、ディスカバリーが成功しなかった場合、TADDM は次に、エンドポイントへの直接接続を使用します。同様に、IBM Tivoli Monitoring を使用したディスカバリーが優先指定されておらず、エンドポイントへの直接接続が成功しなかった場合、TADDM は IBM Tivoli Monitoringを使用してエンドポイントに接続しようとしますが、この場合も、IBM Tivoli Monitoring を使用したエンドポイントのディスカバリーが許可されていることが前提となります。

また、このプロパティーを使用して、次の例で示すようなカスタム・ディスカバリー・スコープを指定することもできます。

com.ibm.cdb.session.prefer.ITM.ip_address=false以下の例では、TADDM がディスカバリー・スコープ 10.20.30.40を使用し、Tivoli Monitoring エンドポイントに直接接続するよう指定しています。

com.ibm.cdb.session.prefer.ITM.10.20.30.40=false

com.ibm.cdb.session.prefer.ITM.Level_3_Discovery=falseデフォルト値は false です。これは、レベル 3 ディスカバリー・プロファイルを使用する場合は TADDM が Tivoli Monitoring エンドポイントに直接接続しますが、他のすべてのディスカバリー・レベルでは、TADDM は以下のプロパティーの値に基づき、IBM Tivoli Monitoring を使用してTivoli Monitoring エンドポイントをディスカバーすることを意味します。

v com.ibm.cdb.session.allow.ITM

v com.ibm.cdb.session.prefer.ITM

このプロパティーは、レベル 3 ディスカバリー・プロファイルを使用する場合に、TADDM が IBM Tivoli Monitoring を使用して TivoliMonitoring エンドポイントをディスカバーするかどうかを指定します。

この値を true に設定すると、TADDM は IBM Tivoli Monitoring を使用して、レベル 3 ディスカバリー・プロファイルから Tivoli Monitoring エンドポイントをディスカバーします。

TADDM サーバーとポータル・サーバーの間の接続をチューニングするためのプロパティー

IBM Tivoli Monitoring レベル 2 ディスカバリーでは、TADDM サーバーとTivoli Enterprise Portal Server の間の接続に遅れが生じた場合、TADDM は以下の TADDM サーバー・プロパティーを使用して接続回復動作をチューニングします。

com.collation.discover.agent.ITM.CmdWrapperSelectionPattern=このプロパティーは、IBM Tivoli Monitoring 環境経由でディスカバリーを実行するときにスクリプトがラップする必要のあるコマンドを指定します。


com.collation.platform.session.ITMSessionConnectionCooldownPeriod=60000このプロパティーは、失敗が検出されてから Tivoli Enterprise PortalServer への接続を再初期化するまでに待機する時間間隔を、ミリ秒単位で指定します。

com.collation.platform.session.ITMSessionConnectionRetryLimit=5このプロパティーは、初期接続が失敗した場合、エラーを報告する前にその接続へのアクセスを試みる回数を指定します。

com.collation.platform.session.ITMSessionNumProgressChecks=600このプロパティーは、その接続が失敗する前に接続の進行状況を検査する回数を指定します。

com.collation.platform.session.ITMSessionProgressCheckInterval=1000このプロパティーは、各接続の進行状況検査を行う時間間隔を、ミリ秒単位で指定します。

OSLC 自動化セッションを使用したディスカバリーのプロパティー:

これらのプロパティーは、OSLC 自動化セッションを使用したディスカバリーに適用されます。

OSLC を介した統合に関連するプロパティー

com.ibm.cdb.topobuilder.integration.oslc.automationproviderこのプロパティーは、Jazz SM Registry Services に登録されていないOSLC Execute Automation Service Provider の直接 URL アドレスを指定します。

以下の例は、ITM の OSLC Execute Automation Service Provider のURL アドレスを示しています。

com.ibm.cdb.topobuilder.integration.oslc.automationprovider=http://<AUTOMATION_PROVIDER_INSTALLATION_HOST>:15210/itmautomationprovider

以下の例は、複数の OSLC Execute Automation Service Provider の URLアドレスを指定する方法を示しています。

com.ibm.cdb.topobuilder.integration.oslc.automationprovider.1=http://9.1.1.1:15210/itmautomationprovidercom.ibm.cdb.topobuilder.integration.oslc.automationprovider.2=http://9.2.2.2:15210/itmautomationprovider

com.ibm.cdb.topobuilder.integration.oslc.automation.scope.alwaysrefresh=falseデフォルト値は false です。

このプロパティーは、OSLCAutomationAgent が実行のたびにスコープ・セットを再作成するかどうかを指定するグローバル・プロパティーです。スコープ・セットを再作成するには、Jazz SM Registry Services またはOSLC Execute Automation Service Provider (あるいはその両方) に接続する必要があります。

このプロパティーに true を設定した場合、エージェントは、スコープ・セットを再作成します。エージェントを最後に実行して以降、OSLC ExecuteAutomation Service Provider が提供する自動化プランが変更されなかった場合でも、スコープ・セットは再作成されます。

管理 93

com.ibm.cdb.topobuilder.integration.oslc.frsurlこのプロパティーは、OSLC 経由で他の製品と統合する際に使用されるJazz SM Registry Services (FRS) の IP アドレスを指定します。 Jazz SMRegistry Services のアドレスは、以下の形式で指定する必要があります。

protocol://ip_or_hostname:port

このプロパティーは、OSLCAgent によっても使用されます。

com.ibm.cdb.topobuilder.integration.oslc.automation.frsurlこのプロパティーは、Jazz SM Registry Services (FRS) の登録コレクションの IP アドレスを絶対パスの形で指定します。これを使用できるのは、Jazz SM Registry Services がデフォルトの /oslc 以外のサービス・パスを使用するときです。

自動化セッションを使用したディスカバリーに関連するプロパティー

com.ibm.cdb.session.oslcautomation.pluginId=com.ibm.cdb.session.oslcautomation_1.0.0

デフォルト値は com.ibm.cdb.session.oslcautomation_1.0.0 です。

このプロパティーは、OSLC 自動化セッション・プラグインの OSGI バンドル ID を指定します。

com.ibm.cdb.session.itm.endpointClass=com.collation.platform.session.oslcautomation.OSLCAutomationEndpoint

デフォルト値は com.collation.platform.session.oslcautomation.OSLCAutomationEndpoint です。

このプロパティーは、使用するエンドポイント・クラスを指定します。

com.ibm.cdb.session.allow.OSLCAutomation=trueデフォルト値は true です。

このプロパティーは、ディスカバリー時に TADDM が OSLC 自動化セッションを使用できるかどうかを指定するスコープ付きプロパティーです。

使用例を以下に示します。

com.ibm.cdb.session.allow.OSLCAutomation=truecom.ibm.cdb.session.allow.OSLCAutomation.9.100.1.0=truecom.ibm.cdb.session.allow.OSLCAutomation.scope_set2=true

com.ibm.cdb.session.prefer.OSLCAutomation=trueデフォルト値は true です。

このプロパティーは、OSLC 自動化セッションをディスカバリーの優先セッションにするかどうかを指定するスコープ付きプロパティーです。このプロパティーの値は、他のどの設定済みの値 (標準 ITM セッションなど) よりも優先されます。

使用例を以下に示します。

com.ibm.cdb.session.prefer.OSLCAutomation=truecom.ibm.cdb.session.prefer.OSLCAutomation.9.100.100.200=truecom.ibm.cdb.session.prefer.OSLCAutomation.scope_name1=true

com.ibm.cdb.session.oslcautomation.timeout.httpconnect=60000デフォルト値は 60000 (60 秒) です。この値はミリ秒単位で表されます。


このプロパティーは、OSLC Execute Automation Service Provider に対する接続のタイムアウトを指定するグローバル・プロパティーです。

com.ibm.cdb.session.oslcautomation.timeout.httpread=240000デフォルト値は 240000 (4 分) です。この値はミリ秒単位で表されます。

このプロパティーは、OSLC Execute Automation Service Provider からデータを読み取る場合のタイムアウトを指定するグローバル・プロパティーです。

com.ibm.cdb.session.oslcautomation.request.async.maxretries=60デフォルト値は 60 です。

このプロパティーは、非同期に生成された AutomationResults に対する連続要求の最大数を指定するグローバル・プロパティーです。

com.ibm.cdb.session.oslcautomation.request.async.delay=10000デフォルト値は 10000 (10 秒) です。この値はミリ秒単位で表されます。

このプロパティーは、非同期で生成された AutomationResults に対する連続要求間の遅延時間を指定するグローバル・プロパティーです。

注: Fix Pack 4 タイムアウトの問題でサーバーへの SSH セッションが失敗する場合は、以下のプロパティーに最適な値を構成してみてください。

com.collation.mindterm.Ssh2Preferences= hello-timeout=30; alive = 25;compression= 9

com.collation.discover.agent.app.packagedapp.mysap.SLDServerPortList =51200 このプロパティーにより、SLD ポートを変更でき、指定したポートをセン

サー構成に追加できます。

com.ibm.cdb.security.auth.cache.itm.disabled=trueデフォルト値は true です。

このプロパティーは、OSLC ディスカバリーに対して資格情報のキャッシュを無効にするかどうかを決定します。


DNS ルックアップ・カスタマイズ・プロパティーこれらのプロパティーは、DNS ルックアップ・カスタマイズに適用されます。

com.collation.platform.os.disableDNSLookups=falseデフォルト値は false です。

有効値は true または false です。このプロパティーを true に変更すると、TADDM サーバーで DNS ルックアップが無効になります。

com.collation.platform.os.disableRemoteHostDNSLookups=falseデフォルト値は false です。

有効値は true または false です。このプロパティーを true に変更すると、ディスカバーされたリモート・ホストで名前検索 (DNS のみ) が無効

管理 95

になります。このプロパティーによって、すべての名前検索が TADDM サーバー上で実行されるように強制されます。

com.collation.platform.os.command.fqdn=nslookup $1 | grep Name | awk'{print $2}'

The default value is nslookup $1 | grep Name | awk '{print $2}'.

このコマンドは、完全修飾ドメイン名 (fqdn) の検索で使用します。ほとんどの場合、実稼働環境ではデフォルトの完全修飾ドメイン名 (FQDN) アルゴリズムが機能しているため、このプロパティーは必要ありません。このプロパティーが不要である場合、コメント化する必要があります。ただし、完全修飾ドメイン名がホスト名から派生している環境では、このプロパティーを使用可能にすることをお勧めします。例えば、DNS でホスト名が別名として構成されている場合は、このプロパティーを有効にします。

このプロパティーを使用する場合、DNS が使用可能で、適切に構成されていることを確認してください。そうでない場合、nslookup コマンドは失敗するか、応答時間が遅くなる可能性があります。

使用可能に設定されている場合、このプロパティーは TADDM サーバーでのみ使用されます。現在、AIX オペレーティング・システムと Linux オペレーティング・システムのみがサポートされています。このプロパティーはWindows TADDM サーバーではサポートされていません。

GUI プロパティーこれらのプロパティーは、TADDM GUI に適用されます。

Fix Pack 3

com.ibm.cdb.gui.supportedJRE.warning=true

このプロパティーは、ディスカバリー管理コンソールが開始される際に警告メッセージ CTJTG0034E が表示されるかどうかを指定します。このメッセージは、ご使用の Java ランタイム環境のバージョンがサポートされていないことを警告します。サポートされないバージョンの Java ランタイム環境で TADDM を使用する場合で、このメッセージが表示されないようにするには、このプロパティーを false に設定します。

このプロパティーのデフォルト値は true です。

GUI JVM メモリー・プロパティー:

これらのプロパティーは、GUI JVM メモリーに適用されます。

com.collation.gui.initial.heap.size=128m

デフォルト値は 128m です。TADDM ユーザー・インターフェースの初期ヒープ・サイズ。

com.collation.gui.max.heap.size=512m

デフォルト値は 512m です。TADDM ユーザー・インターフェースの最大ヒープ・サイズ。

これらのプロパティーは、小規模な TADDM ドメイン向けです。見積もりの目安として、TADDM サーバー数を基にした以下のカテゴリーを使用しています (サーバー同等物に基づく)。

v 小: サーバー同等物が 1000 個まで


v 中: サーバー同等物が 1000 から 2500 個まで

v 大: サーバー同等物が 2500 から 5000 個まで

中規模および大規模環境の場合にこれらの値を大きくすると、一部の GUI 操作のパフォーマンスが向上します。アクション実行時に TADDM が十分なメモリーを利用できない場合、一部のビューは正常に表示されません。

中規模環境の場合:


デフォルト値は 256m です。



大規模環境の場合:





GUI ポート・プロパティー:

これらのプロパティーは、GUI ポートに適用されます。

com.collation.tomcatshutdownport=9436 (TADDM 7.3.0 のみ)デフォルト値は 9436 です。

このポートは Tomcat シャットダウン・コマンドで使用されます。

com.ibm.cdb.service.web.port=9430デフォルト値は 9430 です。

HTTP ポートは SSL なしで使用されます。

com.ibm.cdb.service.web.secure.port=9431デフォルト値は 9431 です。

HTTPS ポートは SSL で使用されます。

com.ibm.cdb.service.ClientProxyServer.port=9435デフォルト値は 9435 です。

SSL なしで使用する RMI データ・ポート。

com.ibm.cdb.service.SecureClientProxyServer.secure.port=9434デフォルト値は 9434 です。

SSL で使用する RMI データ・ポート。

com.ibm.cdb.service.registry.public.port=9433デフォルト値は 9433 です。

公開サービス・レジストリーのポート。

管理 97

LDAP プロパティーこれらのプロパティーは、LDAP に適用されます。

ユーザー認証に外部 LDAP サーバーを使用できます。外部 LDAP サーバーでは、匿名認証とパスワード・ベース認証の両方がサポートされます。

LDAP サーバーのホスト名、ポート番号、ベース識別名、バインド識別名、およびパスワード (パスワード・ベース認証に必要) は collation.properties ファイルで構成できます。検索可能な特定の命名属性をユーザー ID (UID) に一致するように構成することもできます。

同期サーバーおよびドメイン・サーバーのデプロイメントでは、LDAP 構成が推奨されます。エンタープライズ環境では、同じユーザー・レジストリーを使用するようにドメイン・サーバーと同期サーバーを構成してください。同期サーバーに接続されたドメイン・サーバーにログインする場合、ログインは同期サーバーで処理されます。同期サーバーとドメイン・サーバーの間でネットワーク接続の問題が発生した場合でも、同期サーバーと同じユーザー・レジストリーを使用するようにドメイン・サーバーが構成されていれば、再構成を行うことなく、ドメイン・サーバーに正常にログインできます。

com.collation.security.auth.ldapAuthenticationEnabled=trueデフォルト値は true です。

このプロパティーは、LDAP 認証を使用可能にするために使用されます。

com.collation.security.auth.ldapBaseDN=ou=People,dc=ibm,dc=comデフォルト値は ou=People,dc=ibm,dc=com です。

このプロパティーは LDAP ベース識別名 (DN) を定義します。 LDAP ベース識別名は、すべての LDAP 検索の開始点になります。

com.collation.security.auth.ldapBaseGroupDNcollation.properties ファイルでは、このプロパティーはデフォルトでコメント化されています。

このプロパティーは、グループを検索するための LDAP ルート・ブランチを定義します。このブランチは、全 LDAP 照会のためのルート・ブランチとは異なる可能性があります。グループを検索するための LDAP ルート・ブランチを複数指定するには、セミコロン (;) を使用してブランチ名を区切ります。

このプロパティーに値を指定しない場合、デフォルト値はcom.collation.security.auth.ldapBaseDN プロパティーの値になります。

com.collation.security.auth.ldapBindDN=uid=ruser,dc=ibm,dc=comデフォルト値は uid=ruser,dc=ibm,dc=com です。

単純認証を使用する場合、このプロパティーは、LDAP に対する認証で使用されるユーザー ID を定義します。

重要:

v com.collation.security.ldapBindDN の値が指定されていない場合、またはプロパティーがコメント化されている場合は、LDAP への匿名接続


が試行されます。以下の例は、番号記号 (#) を使用してプロパティーをコメント化する方法を示しています。

#com.collation.security.auth.ldapBindDN=uid=ruser,dc=ibm,dc=com

v com.collation.security.auth.ldapBindDN に値が指定されている場合は、単純認証が使用されます。また、その場合は、com.collation.security.auth.ldapBindPassword の値も指定する必要があります。

com.collation.security.auth.ldapBindPassword=ruserデフォルト値は ruser です。

単純認証を使用する場合、このプロパティーは、LDAP に対する認証で使用されるユーザー・パスワードを定義します。

com.collation.security.auth.ldapClientKeyStore=ks_pathこのプロパティーは、証明書を含む鍵ストアの TADDM サーバー上でのロケーションを定義します。このストアには、TADDM サーバーを LDAP サーバーで認証するためのクライアント証明書が含まれている必要があります。

com.collation.security.auth.ldapClientKeyStorePassphrase=ks_passphraseオプション: このプロパティーは、鍵ストアに対するパスワードを定義します。

com.collation.security.auth.ldapClientTrustStore=ts_pathこのプロパティーは、証明書を含むトラストストアの TADDM サーバー上でのロケーションを定義します。このストアには、LDAP サーバー証明書が含まれている必要があります。

com.collation.security.auth.ldapClientTrustStorePassphrase=ts_passphraseオプション: このプロパティーは、トラストストアに対するパスワードを定義します。

com.collation.security.auth.ldapGroupMemberAttribute=memberデフォルト値は member です。

このプロパティーは、LDAP のグループのメンバーを格納するために使用する属性の名前を定義します。

com.collation.security.auth.ldapGroupNamingAttribute=cnデフォルト値は cn です。

このプロパティーは、LDAP のグループの命名に使用する属性の名前を定義します。

com.collation.security.auth.ldapGroupObjectClass=groupofnamesデフォルト値は groupofnames です。

このプロパティーは、LDAP のユーザー・グループを表すために使用するクラスを定義します。

com.collation.security.auth.ldapHostName=ldap.ibm.comデフォルト値は ldap.ibm.com です。

このプロパティーは LDAP サーバーのホスト名を定義します。

管理 99

com.collation.security.auth.ldapPortNumber=389デフォルト値は 389 です。

このプロパティーは LDAP サーバーのポートを定義します。

com.collation.security.auth.ldapUIDNamingAttribute=uidデフォルト値は uid です。

このプロパティーは、LDAP のユーザーの命名に使用する属性の名前を定義します。

com.collation.security.auth.ldapUserObjectClass=personデフォルト値は person です。

このプロパティーは、LDAP のユーザーを表すために使用するクラスの名前を定義します。

com.collation.security.auth.ldapUseSSL=falseデフォルト値は false です。

このプロパティーは、SSL 接続での LDAP ユーザー・レジストリーへの認証を使用可能にするために使用されます。

com.collation.security.usermanagementmodule=ldapデフォルト値は ldap です。

このプロパティーは、TADDM サーバーが使用するユーザー管理モジュールを定義します。有効な値は以下のとおりです。

v file: ファイル・ベースのユーザー・レジストリー。デフォルト値はtrue です。

v ldap: LDAP ユーザー・レジストリー

v vmm: WebSphere Application Server の Federated Repositories を使用するユーザー・レジストリー

ロックアウト・プロパティーこれらのプロパティーは、ロックアウトに適用されます。

com.collation.security.lockout.treshold=3デフォルト値は 3 です。

このプロパティーは、特定のユーザーのログイン試行失敗回数を指定します。この回数に達すると、そのユーザーに対するローカル・ロックアウトがトリガーされます。

com.collation.security.lockout.timeout=30デフォルト値は 30 です。

このプロパティーは、ローカル・ロックアウトがトリガーされた場合に、そのローカル・ロックアウトをトリガーしたユーザーが TADDM からロックアウトされる時間を分単位で指定します。

com.collation.security.lockout.globalthreshold=100デフォルト値は 100 です。

このプロパティーは、グローバル・ロックアウトをトリガーする、単一ユーザーの同時ロックアウト数を指定します。


com.collation.security.lockout.globaltimeout=30デフォルト値は 30 です。

このプロパティーは、グローバル・ロックアウトがトリガーされた場合に全ユーザーが TADDM からロックアウトされる時間を分単位で指定します。

com.collation.security.lockout.failedloginthreshold=1000デフォルト値は 1000 です。

このプロパティーは、グローバル・ロックアウトをトリガーする、固有ユーザーのログイン試行失敗の合計回数を指定します。

ロギング・プロパティーこれらのプロパティーは、ロギングに適用されます。

com.collation.log.filesize=20MBデフォルト値は 20MB です。

ログ・ファイルの最大サイズです。ファイルがこのサイズ制限に到達すると、新規ログ・ファイルが作成されます。現在のログ・ファイルはファイル拡張子 .N が付けられて保管されます。 N は、1 から、com.collation.log.filecount プロパティーに設定された値までの数字です。 com.collation.log.filecount プロパティーには、作成および保持できるログ・ファイル数を設定します。このファイル数に到達すると、ログ・ファイルが循環します。

直接バイト数を入力するか、キロバイトまたはメガバイト数を KB およびMB を使用して指定できます。

次の例は、有効なログ・ファイル・サイズ値です。

v 1000000

v 512 KB

v 10 MB

com.collation.log.filecount=5デフォルト値は 5 です。

保持するログ・ファイルの数です。

com.collation.log.level.vm.vmName=INFOデフォルト値は INFO です。

各仮想システムのログ・レベルを設定します。

vmName は、TADDM サービス名に関連付けられた Java 仮想システムです。その他の有効なオプションを次に示します。

v Topology

v DiscoverAdmin

v EventsCore

v Proxy

v Discover

v EcmdbCore

v StorageService

管理 101

v DiscoveryService

その他の有効なオプションを次に示します。

v FATAL

v ERROR

v WARNING

v INFO

v DEBUG (DEBUG オプションを設定すると、システム・パフォーマンスが低下します。)

v TRACE (TRACE オプションを設定すると、パスワードがログに記録されます。)

パフォーマンス・プロパティーこれらのプロパティーは、TADDM パフォーマンスに適用されます。

com.collation.discover.dwcount=32デフォルト値は 32 です。値は整数でなければなりません。

このプロパティーは、ディスカバリー速度に影響を及ぼします。ディスカバー・ワーカー・スレッドは、センサーを実行するスレッドです。このプロパティーは、同時に実行可能なディスカバー・ワーカー・スレッドの数を指定します。これは、ストリーミング・サーバー・デプロイメントのディスカバリー・サーバー、またはドメイン・サーバー・デプロイユーザーのドメイン・サーバーのみに適用されます。

IBM Tivoli Monitoring を使用したディスカバリー (以前に採用されていたIBM Tivoli Monitoring スコープ・センサーを使用する方式) の場合、この値は 16 に設定する必要があります。それ以外のタイプのディスカバリーの場合、値の有効な範囲は 32 から 160 です。

com.collation.discover.observer.topopumpcount=16デフォルト値は 16 です。値は整数でなければなりません。

このプロパティーは、ディスカバリー結果を TADDM データベースに保管する速度に影響を及ぼします。このプロパティーは、TADDM データベースとの通信のために作成されるライター・スレッドの数を指定します。

ストリーミング・サーバー・デプロイメントのディスカバリー・サーバーの場合、このプロパティーは、ディスカバリー・サーバーがディスカバリー結果をストレージ・サーバー・プールに送信するために使用するスレッドの数を制御します。

ストリーミング・サーバー・デプロイメントのストレージ・サーバーの場合、このプロパティーは、ディスカバリー結果をディスカバリー・サーバーから受信するためのスレッドの数を制御します。

ドメイン・サーバー・デプロイメントのドメイン・サーバーの場合、このプロパティーは、ディスカバリー結果をディスカバー・ワーカー・スレッドから受信するためのスレッドの数を制御します。


これらのスレッドは、接続プールからのデータベース接続を使用して (結果を保管したりデータを取得したりするために) TADDM データベースと通信します。プールされた JDBC 接続がそれ以上無くなると、スレッドは非プール接続を作成します。

com.ibm.cdb.discover.observer.topopump.threshold=0.7com.ibm.cdb.discover.observer.topopump.threshold.topo_agent_grp_name=0.7

デフォルト値は 0.7 です。この値は浮動小数点定数でなければなりません。

このプロパティーは、トポロジー・エージェントの実行中に開始できるデータベース・ライター・スレッドの部分を指定します。しきい値は、特定のエージェント・グループに対して個別に指定することも、すべてのエージェント・グループに対して一度に指定することもできます。エージェント・グループに対する値が定義されていない場合は、汎用しきい値が使用されます。この値によって、トポロジー・エージェントの実行時に TADDM データベースにディスカバリー結果を保管するスレッドの制限を設定できます。

com.ibm.cdb.typesServiceRefreshInterval=120デフォルト値は 120 です。最小値は 30 で、最大値は 1800 です。

このプロパティーは、カスタム照会の作成、変更履歴の表示、またはコンポーネント比較情報の表示の際にコンポーネント・タイプを更新するためのリフレッシュ間隔を秒単位で指定します。

com.ibm.cdb.ea.metaRefreshFrequency=20デフォルト値は 20 です。値は整数でなければなりません。

このプロパティーは、(ストレージ・サーバーなどの) 定義済みの拡張属性に関する情報を更新するリフレッシュ間隔 (秒単位) を指定します。

セキュア・シェル (SSH) プロパティーこれらのプロパティーは、セキュア・セル (SSH) に適用します。

Fix Pack 1

com.ibm.cdb.platform.SshVersionSessionSkipList

このプロパティーは、セッションが確立されない SSH サーバーのバージョンを指定します。これに該当するサーバーの場合、セッション・センサーはエラーを出さずに終了します。

このプロパティーの値は、コンマ区切りリスト (例: Cisco,Data

ONTAP,SSH-2.0-OpenSSH_5.9 PKIX FIPS,OpenSSH_OA) です。

com.collation.SshLogInput=falseデフォルト値は false です。

有効値は true または false です。値を true に設定すると、SSH 入力がログに記録されます。

com.collation.SshPort=22デフォルト値は 22 です。値は整数でなければなりません。

このプロパティーは、サーバーがすべての SSH 接続に使用するポートを指定します。

com.collation.SshSessionCommandTimeout=120000デフォルト値は 120000 です。値は整数でなければなりません。

管理 103

この値は、SSH コマンド実行の許容時間 (ミリ秒単位) を示します。このプロパティーがエージェントから使用される場合に、このプロパティーの設定が有効になるようにするには、このプロパティーの値をAgentRunnerTimeout プロパティーの値よりも小さくする必要があります。

com.collation.SshWeirdReauthErrorList=Permission denied

このプロパティーを使用すると、以前、ディスカバリーの実行時に機能したユーザー名とパスワードのペアを再試行できます。Windows システムでは、有効なログイン操作が不規則に拒否されることがあるため、このプロパティーが必要になります。このプロパティーには、Permission denied 設定が必要です。このプロパティーは変更しないでください。

com.collation.WmiInstallProviderTimeout=240000デフォルト値は 240000 です。値は整数でなければなりません。

この値は、WMI InstallProvider スクリプトの実行を待機できる時間 (ミリ秒単位) を示します。

com.collation.SshSessionReuseSuppressListSSH サーバーの一部のバージョンは、TADDM によって実装された接続の再利用をサポートしません。再利用に対してサポートされないバージョンのSSH サーバーを稼働するターゲットを TADDM が正常にディスカバーするようにするには、それらのバージョンの SSH サーバーをこのプロパティーに追加する必要があります。

このプロパティーの値は、コンマ区切りリストです。 SSH-2.0-BoKS_SSH_6のように、SSH サーバーのバージョンの先頭のみを指定すれば十分です。

SSH サーバーのバージョンは、セッション・センサーのログ・ファイルで確認できます。

セキュリティー・プロパティーこれらのプロパティーは、セキュリティーに適用されます。

Fix Pack 3

com.ibm.cdb.secure.server=false


このプロパティーは、パブリック RMI レジストリーおよび外部 RMI レジストリーからのすべての TADDM サービスがセキュアかどうかを指定します。true に設定すると、セキュアでないすべてのパブリック・サービス(ClientProxyServer および API サーバー) は、内部 RMI レジストリーに移動されます。また、SSL プロトコルがRegistriesURLProvider、SecurityManager、TopologyManager などの外部サービスで実行されます。

このプロパティーを true に設定した場合、com.collation.security.enablesslforconsole プロパティーおよびcom.collation.security.enforceSSL プロパティーも true に設定します。

このプロパティーを設定すると、セキュアでない接続で TADDM に接続する他の製品との統合に影響が及ぶことがあります。

このプロパティーのデフォルト値を変更する場合は、以下のロケーションで設定します。




v すべての TADDM SDK インストール済み環境の sdk/etc/collation.properties。

Fix Pack 5

サーバーがセキュア・モードで実行中

(com.ibm.cdb.secure.server = true) の場合、次のポートは SSL プロトコルを使用して保護されます。

v com.ibm.cdb.service.registry.public.port (デフォルト値: 9433)

サーバーがセキュア・モードで実行中 (com.ibm.cdb.secure.server = true)の場合、データ管理コンソールの起動時に「セキュア (SSL) セッションを確立」チェック・ボックスにチェックマークを付ける必要があります。

Fix Pack 1

com.ibm.cdb.secure.liberty=false


有効値は true または false です。非セキュア HTTP ポートを無効にするには、このフラグを true に設定します。

com.collation.security.privatetruststore=trueデフォルト値は true です。

有効値は true または false です。 SSL が使用可能な場合は、この値はtrue でなければなりません。

com.collation.security.enablesslforconsole=trueデフォルト値は true です。

有効値は true または false です。

com.collation.security.enabledatalevelsecurity=falseデフォルト値は false です。

有効値は true または false です。ユーザーまたはユーザー・グループによる TADDM オブジェクトのコレクションへのアクセスを制限する場合は、この値を true に設定します。

com.collation.security.enforceSSL=falseデフォルト値は false です。

有効値は true または false です。非セキュア接続を無効にして、強制的に SSL 接続を使用する場合は、このフラグを true に設定します。

com.collation.security.usermanagementmodule=fileデフォルト値は file です。

このプロパティーには 3 つのオプションがあります。

v file: TADDM ファイル・ベースのユーザー・レジストリー

v ldap: LDAP ユーザー・レジストリー

v vmm: WebSphere Application Server の Federated Repositories を使用するユーザー・レジストリー

com.collation.security.auth.sessionTimeout=240デフォルト値は 240 です。値は整数でなければなりません。

管理 105

com.collation.security.auth.searchResultLimit=100デフォルト値は 100 です。値は整数でなければなりません。

ユーザー数が多い場合に、このプロパティーを使用します。

重要: LDAP または WebSphere Federated Repositories のユーザー数が100 を超える場合は、予測されるユーザー数に対応できるように、この値を大きくします。例: com.collation.security.auth.searchResultLimit=150

com.collation.security.auth.websphereHost=localhostデフォルト値は localhost です。

WebSphere Application Server の Federated Repositories 機能をホストするシステムの完全修飾ドメイン名を入力します。

com.collation.security.auth.webspherePort=2809デフォルト値は 2809 です。

これは整数値である必要があります。この値は WebSphere システム・ポートを示します。

com.ibm.cdb.service.SecurityManager.port=9540同期サーバー以外のサーバーの場合:


セキュリティー・マネージャーが使用するファイアウォール・ポートを指定します。

同期サーバーの場合:デフォルト値は設定されていません。ドメインは、com.collation.EnterpriseSecurityManager.port パラメーターで指定されるポートを使用して、同期サーバーと通信します。このプロパティーのデフォルト値は 19433 です。

com.collation.cdm.analytics.authorizedRole=

「分析性」ペインは、特定の役割に制限できます。デフォルトでは、このプロパティーは collation.properties ファイルには定義されていないため、「分析性」ペインは全員が使用できます。プロパティーの値は、ペインへのアクセスが許可される役割の名前である必要があります。

「分析性」ペインでの、以下に示す領域へのアクセスは、指定された役割によって決まることがあります。

v Fix Pack 2 グループ化パターン

v インベントリーの要約

v アプリケーションの要約

v サービスの要約

v システム・インベントリー

v ソフトウェア・サーバー・インベントリー

v BIRT レポート

com.collation.security.discoverOutsideScope=trueデフォルト値は true です。


有効値は true または false です。スコープ内にないエレメントのディスカバーを無効にするには、このフラグを false に設定します。

com.ibm.cdb.secure.tomcat=false (TADDM 7.3.0 のみ)デフォルト値は false です。

有効値は true または false です。非セキュア HTTP ポートを無効にするには、このフラグを true に設定します。

com.ibm.cdb.http.ssl.protocol=TLSデフォルト値は TLS です。

このプロパティーは、Web SSL ポート (HTTPS ポート) で使用されるSSL プロトコルを変更します。デフォルトでは、このポートは 9431 です。com.ibm.cdb.service.web.secure.port プロパティーを使用して、このポートを設定できます。

サポートされる値のリストについては、IBM Java 7 の資料(http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/protocols.html) を参照してください。最も安全なプロトコル (例えば、TLS

v1.1 や TLS v1.2) を使用する場合は、最初に、これらのプロトコルをサポートするように Web ブラウザーを構成する必要があります。また、プロトコルが強力すぎる場合は、Web SSL ポートを通じて TADDM に接続する他の製品との統合に影響が及ぶことがあります。

Fix Pack 5

クライアント・サイドで

com.ibm.cdb.http.ssl.protocol=TLSv1.2 と JAVA7 を使用中の場合、次の設定を更新する必要があります。

<JAVA_HOME>/jre/lib/security/java.securityjdk.tls.disabledAlgorithms=SSLv2, SSLv3, TLSv1, TLSv1.1

さらに、ブラウザーで TLSv1 と TLSv1.1 を無効にしてください。

■com.ibm.cdb.ssl.protocol=TLSこのプロパティーは、デフォルトでは collation.properties ファイルに追加されません。追加されない場合、デフォルト値は TLS です。変更するには、このプロパティーを collation.properties ファイルに手動で追加し、新しい値を指定します。

このプロパティーは、以下のポートで使用される SSL プロトコルを変更します。

v API サーバーが SSL 要求を listen するポート。デフォルトでは、9531

です。com.ibm.cdb.service.SecureApiServer.secure.port プロパティーを使用して、このポートを設定できます。

v SSL で使用する RMI データ・ポート。デフォルトでは、9434 です。com.ibm.cdb.service.SecureClientProxyServer.secure.port プロパティーを使用して、このポートを設定できます。

サポートされる値のリストについては、IBM Java 7 の資料(http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/protocols.html) を参照してください。最も安全なプロトコル (例えば、TLS

管理 107

http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jsse2Docs/protocols.html






v1.1 や TLS v1.2) を使用する場合は、最初に、これらのプロトコルをサポートするように Web ブラウザーを構成する必要があります。また、プロトコルが強力すぎる場合は、リストされたポートを通じて TADDM に接続する他の製品との統合に影響が及ぶことがあります。

■com.ibm.cdb.http.ssl.ciphers=暗号が LibertyServer に設定され、指定された暗号でのみ通信が実行されます。それ以外の場合はデフォルトの暗号が使用されますが、アルゴリズムが弱い可能性があります。

■com.ibm.cdb.rmi.ssl.protocol=このプロパティー com.ibm.cdb.rmi.ssl.protocol は、com.ibm.cdb.ssl.protocol で作成された SSL 接続で特定のプロトコルを有効にすることができます。

com.ibm.cdb.rmi.ssl.protocol は、com.ibm.cdb.ssl.protocol の中のサポート対象プロトコルにする必要があります。

■com.ibm.cdb.rmi.ssl.ciphers=このプロパティーを使用して、RMI データ・ポートおよび API サーバーがlisten するポートに対して暗号アルゴリズムを設定できます。

一時ディレクトリー・プロパティーこれらのプロパティーは、一時ディレクトリーの使用に適用されます。

一時ディレクトリーは、特定の条件下で一時ファイルを保管するために TADDMが使用します。例えば、アンカー・ログ・ファイル、ディスカバリー・スクリプト、ディスカバリー結果、およびディスカバリーの実行時に一部のセンサーで必要な情報を、一時ディレクトリーに保管できます。TADDM では、ANCHOR_DIR、ASD_TEMP_DIR、および TADDM_TEMP_ROOT という 3 つの一時ディレクトリーを使用します。

com.ibm.cdb.taddm.anchor.root=.¥デフォルト値は .¥ です。

この項目は、アンカー・サーバーがデプロイされる ANCHOR_DIR ディレクトリーのロケーションを指定します。このプロパティーはスコープ付きプロパティーであり、IP アドレス、スコープの名前、またはオペレーティング・システムをこのプロパティーに付加できます。例:com.ibm.cdb.taddm.anchor.root.SunOS=。

Windows システムの場合、以下のプロパティー名およびデフォルト値が使用されます。

com.ibm.cdb.taddm.anchor.root.Windows=%windir%¥¥temp¥¥

プロパティー値は、ターゲット・ホスト上で解決される変数を使用します。Linux、AIX、および SunOS 変数には、ドル記号 ($) のプレフィックスを付ける必要があります。Windows 用の変数は、% 記号で囲む必要があります。例えば、com.ibm.cdb.taddm.anchor.root=$TMP/taddmdirs/anchor やcom.ibm.cdb.taddm.anchor.root.Windows=%TEMP%¥¥taddmdirs¥¥anchor のようになります。

解決されるプロパティー値が相対ディレクトリー・パスの場合、プレフィックスは次のようになります。


v %windir%¥¥temp¥¥ - Windows の場合

v ホーム・ディレクトリー - AIX、Linux、および SunOS システムの場合

パスにはサフィックスとして、taddmversion/anchor ディレクトリーが付けられます。例えば、/home/taddmusr/taddm7.2.1/anchor やc:¥Windows¥Temp¥taddm7.2.1¥anchor のようになります。

com.ibm.cdb.taddm.asd.tempこの項目は、ASD_TEMP_DIR ディレクトリーのロケーションを指定します。このディレクトリーには、ディスカバリー・スクリプトおよびディスカバリー結果が保管されます。このプロパティーは、スコープ付きプロパティーであり、IP アドレスまたはオペレーティング・システムをこのプロパティーに付加して、カスタマイズすることができます。

指定されたロケーションに、taddmversion/asd/ ディレクトリーが作成されます。例えば、/tmp/taddm7.2.1/asd/ のようになります。新規ロケーションを指定する場合、すべてのユーザーが、その新規ロケーションに対するすべてのアクセス権限を持っている必要があります。

com.ibm.cdb.taddm.file.temp=.¥デフォルト値は .¥ です。

この項目は、TADDM_TEMP_ROOT のロケーションを指定します。このディレクトリーは、ディスカバリーの実行に必要な一時データを保管するために、さまざまなセンサーが使用します。一時データを保管するセンサーの例としては、DB2® センサーおよび WebLogic センサーがあります。

TADDM_TEMP_ROOT ディレクトリーは、ホーム・ディレクトリー内のtaddmversion/temp/ に作成されます。例えば、/home/taddmusr/

taddm7.2.1/temp/ のようになります。

トポロジー・ビルダー・プロパティーこれらのプロパティーは、トポロジー・ビルダーに適用されます。

com.collation.topobuilder.RuntimeGcUnknownServerRetentionSpan=5デフォルト値は 5 です。

このプロパティーは、不明なプロセスを保持する期間 (日単位) を指定します。最大値は 14 です。不明なプロセスによって、カスタム・サーバーのテンプレートが必要な時期が決まりますが、定期的にクリーンアップしないと、不明なプロセスの数は時間とともに増加します。これにより、トポロジー・パフォーマンスの問題が発生する可能性があります。 zOS の「アドレス・スペース」項目は、この処理で削除されません。

com.collation.topobuilder.RuntimeGcThreadCount=デフォルト値は 4 です。

このプロパティーは、パフォーマンスを向上できる並列性を、RuntimeGCエージェントに追加します。

com.collation.topobuilder.agent.DerivedAppToAppDependencyAgent.ServiceDependency.enabled


管理 109

このプロパティーは、ビジネス・アプリケーションのメンバーがサービス依存関係にあるときにトポロジー・エージェント DerivedAppToAppDependencyがそのビジネス・アプリケーション間の依存関係を作成するかどうかを指定します。

そのような依存関係をエージェントが作成できるようにするには、プロパティーを true に設定します。

トポロジー・マネージャー・プロパティーこれらのプロパティーは、トポロジー・マネージャーに適用されます。

com.ibm.JdoQuery.FetchBatchSize=500デフォルト値は 500 です。

バッチ・サイズは構成可能なプロパティーで、kodo.FetchBatchSize プロパティーに対応します。このプロパティーは、実行した照会の結果セットをスクロールするときに一度に取り出す行数を表します。

com.ibm.cdb.service.TopologyManager.port=9550デフォルト値は 9550 です。

トポロジー・マネージャーが使用するファイアウォール・ポートを指定します。

ビュー・マネージャー・プロパティーこれらのプロパティーは、ビュー・マネージャーに適用されます。

Fix Pack 2

com.ibm.taddm.hideNetworkConnectionUnusedColumns.enabled


このプロパティーは、「ネットワーク接続」タブの以下の列がデータ管理ポータルに表示されるかどうかを指定します。

v フロー

v パケット

v オクテット

v 最初

v 最後

これらの列を非表示にするには、このプロパティーを true に設定します。

com.collation.view.maxnodes=500デフォルト値は 500 です。値は整数でなければなりません。

このプロパティーは、データ管理ポータル内のトポロジー・グラフで表示できるノードの最大数を指定します。このプロパティーを高い値に設定すると、より大きなトポロジーを表示できます。ただし、メモリー所要量が増大する可能性があります。

データ保全性の検証verify-data コマンドを実行することで、TADDM データベース内の構成アイテムのデータ保全性を検証できます。検証できるのは、関係、継承マッピング、重複、およびオーバー・マージです。


始める前に

repair オプションを有効にした状態で、ディスカバリー、バルク・ロード、または同期を実行しないでください。データ保全性ツールは大量のデータを分析するため、特に repair オプションを有効にすると、処理を完了するのに幾分時間がかかることがあります。TADDM サーバーが稼働中でなければなりませんが、タスクを一切実行していないことを確認してください。


データ保全性検証ツールは、TADDM データベースにある構成アイテムのデータ保全性の問題を報告し、修復します。実行可能スクリプトは $COLLATION_HOME/bin ディレクトリーにあります。ツールは報告を行い、verify-data.log ファイルにログを作成します。ツールの停止および再実行は、いつでも行うことができます。

関係の検証関係の検証では、すべてのモデルおよび交差テーブルで、外部キーを照会し、検証します。


repair オプションが有効な場合、関係の検証では、親オブジェクトがデータベース内に存在しなければ子オブジェクトが削除され、包含関係ではないと定義された関係については、無効な外部キーの値がクリアされます。また、下位の構成アイテムが大量に削除されることもあります。ただし、アイテムに親オブジェクトがなければ、アイテムを削除しても安全です。

手順

関係を検証するには、以下のいずれかのコマンドを実行します。

v verify-data.sh -v ro [-a repair]

v verify-data.bat -v ro [-a repair]

継承マッピングの検証継承マッピングの検証では、構成アイテム・クラスをマップするすべてのテーブルを照会し、各行についての項目がすべてのテーブルに含まれていることを検証します。


repair オプションが有効な場合、レコードが再作成されます。

手順

継承マッピングを検証するには、以下のいずれかのコマンドを実行します。

v verify-data.sh -v io [-a repair]

v verify-data.bat -v io [-a repair]

管理 111

重複の検証重複の検証では、データベース内の命名規則フィールド値に基づいて、重複した構成アイテムがないか検索します。


repair オプションを有効にすると、重複したオブジェクトはマージされます。マージ後は、永続的オブジェクトがデータベース内に残り、一時的オブジェクトは削除されます。

マージは複数のスレッドで並行して実行されます。デフォルトのスレッド数は 5 です。以下の例に示すように、collation.properties ファイルでcom.ibm.cdb.topomgr.dataverification.generator.ThreadCount フラグを適切な数に設定することによって、スレッド数を変更することができます。

v com.ibm.cdb.topomgr.dataverification.generator.ThreadCount=10

スレッド数を変更した後は、TADDM サーバーを再始動する必要があります。

オブジェクトのマージ中に、いくつかのエラーが発生することがあります。エラーの原因は、ログ・ファイルに記載されます。

v ERROR_INVALID_DURABLE_GUID

v ERROR_INVALID_TRANSIENT_GUID

エラーの原因は、別名テーブル内で別名が欠落しているか、オブジェクトが無効であるかです。無効なオブジェクトをクリーンアップ・エージェントが削除するのを待機する必要があります。

手順

重複を検証するには、以下のいずれかのオプションを実行します。

v verify-data.sh -v dup [-a repair]

v verify-data.bat -v dup [-a repair]

オーバー・マージの検証オーバー・マージの検証では、ALIASES_JN テーブルに収集されたデータを使用して、マスター別名の変更が多い GUID が検出および報告されます。


ALIASES_JN テーブルには、ALIASES テーブルへの変更の履歴が含まれています。オーバー・マージとは、いくつかのオブジェクトがその親を同じモデル・オブジェクトに変更した状態のことです。そうした子オブジェクトは、いくつかの親オブジェクトの周辺でクラスター化されます。TADDDM 7.2.1 フィックスパック 3がインストールされる以前に発生したオーバー・マージは、ALIASES_JN テーブル内に必要なデータが存在しないため、検出できません。誤検出の結果が検出されて報告される場合があるため、検証には repair オプションはありません。

デフォルトでは、ComputerSystem、AppServer、Operating System の各クラス、およびそれらのクラスから継承されるその他のすべてのクラスに対して、詳細なト


ラッキングが使用可能です。さまざまなクラスに対してトラッキングを使用可能にする場合は、collation.properties ファイルにある次のプロパティーを編集することができます。

com.ibm.tivoli.namereconciliation.service.overmergeClasses

以下に、ComputerSystem、AppServer、および Operating System クラスを探すために指定するプロパティーの例を示します。

com.ibm.tivoli.namereconciliation.service.overmergeClasses=ComputerSystem,AppServer,OperatingSystem

コマンドを実行するために使用されるアクションの意味:

v s1s2s1 - 検証で、命名属性の値をループで変更する CI を探します。例えば、シグニチャーが A、次に B、再び A の順に、それらのシグニチャーのコンピューター・システムが検出されます。

v s1s2s3 - 検証で、指定された命名属性についていくつかの変更を含んだ CI を探します。

v m1m2m1 - 検証で、GUID がそのマスター GUID を何回も変更した CI を探します。例えば、後でマスター GUID C に割り当てられ、その後再びマスターGUID B に再割り当てされた、マスター GUID が B の別名 A が検出されます。

v m1m2m3 - 検証で、GUID がそのマスター GUID を 2、3 回変更した CI を探します。

v WinCSLinCSWinCS - 検証で、タイプを 2、3 回変更した CI を探します。例えば、最初は WindowsComputerSystem として保管され、後でLinuxUnitaryComputerSystem に更新され、その後再びWindowsComputerSystem に更新されたコンピューター・システムが検出されます。

手順

オーバー・マージを検証するには、以下のいずれかのコマンドを実行します。

v verify-data.sh -v om [-a <action>] [-p <class>] [-from <time stamp>][-to <time stamp>]

v verify-data.bat -v om [-a <action>] [-p <class>] [-from <time stamp>][-to <time stamp>]

各項目の意味は以下のとおりです。

– <action>: s1s2s1、s1s2s3、m1m2m1、m1m2m3、WinCSLinCSWinCS

– <class>: TADDM モデルの任意のクラス、例えば、ComputerSystem。

– <time stamp>: YYYY-MM-DD HH24:MI:SI 形式のタイム・スタンプ。

例verify-data.sh -v om -a s1s2s1 m1m2m1 WinCSLinCSWinCS-p ComputerSystem -from 2012-11-13 14:50:00 -to 2012-11-14 14:50:01

このコマンドは、2012 年 11 月 13 日の 14:50:00 と 2012 年 11 月 14 日の14:50:01 の間に作成された、ComputerSystem クラスおよびそのクラスから継承されたすべてのクラスについて、タイプが s1s2s1、m1m2m1、および

管理 113

WinCSLinCSWinCS のオーバー・マージを探します。

オーバー・マージの問題の解決:

オーバー・マージは、いくつかのオブジェクトがその親を同じモデル・オブジェクトに変更したときに発生します。そうした子オブジェクトは、いくつかの親オブジェクトの周辺でクラスター化されます。

手順

1. オーバー・マージ検証を実行します。

2. 報告された構成アイテムを確認します。検証では、誤って当該アイテムをオーバー・マージと報告する場合もあります。

3. オーバー・マージの原因となっている可能性がある、環境内の構成を修正します。構成の問題には、シグニチャー、シリアル番号、VMID、およびその他のCI 命名属性が同一であることなどがあります。

4. オーバー・マージされたオブジェクトを TADDM データベースから削除します。

5. 削除されたオブジェクトについてのディスカバリーを実行し、結果を検証します。

6. オーバー・マージの問題をすべて解決した後、ALIASES_JN テーブルからすべてのレコードを削除します。

資格情報キャッシュの管理 - cachemgr ユーティリティーcachemgr.sh または cachemgr.bat コマンドを使用して、資格情報キャッシュの内容をリストしたり、削除したりすることができます。

コマンド構文

cachemgr -h | -u user -p password (-l|-r) valid|invalid|all [[ -s IP|scope|scopegroup|range|subnet ] [ -a addressSpace ] [ -n accessCredentialName ] [ -c type ] [-d yyyy/mm/dd ] [ -k key ] [ -t locationTag ]]

パラメーター

-a, --addressSpace addressSpace

アドレス・スペース名。

-c, --class type

選択されたアクセス・エントリーのタイプで、アクセス・エントリーを実装する特定のクラスの名前によって記述されます。

-d, --date yyyy/mm/dd

指定の時刻まで変更されない項目を選択するために使用される日付しきい値。形式は yyyy/mm/dd です。

-h, --helpヘルプを表示します。

-k, --key key

選択されたキャッシュ項目のキー。


-l, --list valid|invalid|all

以下の引数によって制御されるリスト作成操作。

v valid - キャッシュに保持されている有効な認証試行のみをリストします。

v invalid - キャッシュに保持されている無効な認証試行のみをリストします。

v all - キャッシュに保持されている有効な認証試行と無効な認証試行の両方をリストします。

-n, --name accessCredentialName

アクセス資格情報の名前 (アクセス・リストにあるものと同じ)。

-p, --password password

TADDM サーバーにログインするユーザーのパスワード。

-r, --remove valid|invalid|all

以下の引数によって制御される除去操作。

v valid - キャッシュに保持されている有効な認証試行のみを除去します。

v invalid - キャッシュに保持されている無効な認証試行のみを除去します。

v all - キャッシュに保持されている有効な認証試行と無効な認証試行の両方を除去します。

-s, --scope IP|scope|scope group|range|subnet

アクセス・エントリーのスコープ。以下の引数によって制御されます。

v IP

v scope

v scope group

v range

v subnet

-t, --locationTag locationTag

選択されたアクセス・エントリーのロケーション・タグ。

-u, --username username

TADDM サーバーにログインするユーザー。

例v 以下のコマンドは、スコープ ScopeSet 内のコンピューターのすべての無効な認

証試行をリストします。

cachemgr.sh -u user -p password -l invalid -s ScopeSet

このコマンドによって、以下の出力が生成されます。

Following entries are matching provided criteria:CachedAuthEntryguid: 3B954CE4CFBF346C8DF538F09F1F7FFDkeyString: SSH!9.128.109.144!!com.collation.platform.security.auth.HostAuth!null!lastModified: Thursday, 5 September 2013 11:00:38Authorization: invalid. Error message: CTJTP1190E The server did not completethe authorization process.CachedAuthEntryguid: ACC2F35A66D3379BAC13FC606C5A08A3keyString: SSH!9.128.109.145!!com.collation.platform.security.auth.HostAuth!null!lastModified: Thursday, 5 September 2013 11:00:38Authorization: invalid. Error message: CTJTP1190E The server did not completethe authorization process

管理 115

v 以下のコマンドは、9.123.149.10 から 9.123.149.12 までの IP 範囲と、アクセス・エントリー com.collation.platform.security.auth.HostAuth 内にある無効な認証試行を削除します。

cachemgr.sh -u user -p password -r invalid -s 9.123.149.10-9.123.149.12-c com.collation.platform.security.auth.HostAuth

このコマンドによって、以下の出力が生成されます。

AuthEntries removed from cache successfully (2).

Cachemgr ユーティリティーの戻りコード

cachemgr ユーティリティーを呼び出す cron スクリプトまたは他のスクリプトを作成する場合、以下の戻りコードが、プログラムの終了方法を示します。

0 プログラムは正常に完了しました。

1 無効なコマンド行パラメーターが指定されました。パラメーター自体、またはパラメーターに指定されたデータが正しくありません。コマンドを訂正し、再試行してください。

2 date コマンド行パラメーターが、予期される形式になっていません。

3 提供されたスコープ定義が、どの IP アドレスにも解決されないか、提供されたアクセス・エントリーが無効です。

4 エラーが発生しましたが、内容は不明です。ログ・ディレクトリーに移動し、cachemgr.log を開いて詳細を確認してください。

5 指定したユーザーに、操作を実行するための十分の特権 (ディスカバリー)がありません。

6 指定された基準に一致する項目がデータベースにありませんでした。

ディスカバリーの準備TADDM がディスカバリー中にご使用の環境から収集する情報を最適化するには、ディスカバリーに対応するよう環境を準備するための構成タスクを実行する必要があります。


具体的な構成タスクは、ご使用の環境でサポートする必要があるディスカバリーのタイプとレベルによって異なります。

次のタスク

ご使用の環境をディスカバリー用に構成するだけでなく、必要に応じて TADDMセンサーを構成する必要があります。これを実行する方法については、TADDM の「センサー解説書」を参照してください。

スコープの定義やスケジュールの設定など、ディスカバリーの実行方法については、TADDM の「ユーザーズ・ガイド」を参照してください。


ユーザー・ログオン ID の構成TADDM でディスカバリーを正常に実行するには、インタラクティブなユーザーが必要です。ユーザー・ログオン ID を構成する必要があります。

対話式ユーザー・ログオン ID は、サーバーとゲートウェイのセッションやゲートウェイとターゲットのセッションなど、すべてのディスカバリー・セッションで非対話式モードで使用されます。コマンドを実行するには、ユーザーがインタラクティブでなければなりません。ただし、コマンドは、非インタラクティブな方法で実行されます。つまり、ユーザーは、コマンドを実行し、その結果を待機します。

/etc/passwd で、ユーザーを以下のように設定します。

taddmusr:x:100:100::/export/home/taddmusr:/bin/sh

ここで taddmusr は、TADDM ユーザー名です。

代替ディスカバリー方式の構成非同期ディスカバリー、スクリプト・ベースのディスカバリー、または IBM TivoliMonitoring を使用したディスカバリーなど、代替ディスカバリー方式を使用するのがふさわしい場合があります。

注:

1. ターゲット・コンピューター・システムが、AIX、FreeBSD、HPNonStop、Linux (x86 システムの場合のみ)、Solaris、または Windows の各オペレーティング・システムを稼働している場合に限り、非同期ディスカバリーとスクリプト・ベースのディスカバリーがサポートされます。

2. ターゲット・コンピューター・システムが Solaris オペレーティング・システムを稼働している場合、SunSSH 1.0 の使用時にはスクリプト・ベースのディスカバリーが機能しないことがあります。

非同期ディスカバリーの構成非同期ディスカバリーを実行するには、まずディスカバリーを構成する必要があります。


非同期ディスカバリーを構成するには、ディスカバリー・スクリプト・パッケージを生成し、そのパッケージをターゲット・システムにコピーし、ターゲット・システムでスクリプトを実行する必要があります。ディスカバリー・スクリプトの出力は、ディスカバリー結果を含むアーカイブ・ファイルです。その後、このアーカイブ・ファイルを TADDM サーバーに移動する必要があります。

注: 非同期モードでディスカバリーを実行するように構成していて、TADDM にアップグレードした場合は、センサー・プラグイン ID が変わる可能性があるため、ディスカバリー・スクリプト・パッケージを再生成する必要があります。

手順

1. ディスカバリー・スクリプト・パッケージを生成するには、$COLLATION_HOME/bin ディレクトリーから、以下のいずれかのコマンドを入力します。

管理 117

v 通常方式

makeASDScriptPackage OUTPUT_DIR UNAME [IPADDRESS] [PACKING_METHOD]

OUTPUT_DIRスクリプト・パッケージのディレクトリー・パス。

UNAMEスクリプトが実行されるターゲット・システムのオペレーティング・システム。有効な値は、AIX、Linux、SunOS、FreeBSD、Windows、または NONSTOP_KERNEL です。

IPADDRESS (オプション)スクリプトが実行されるターゲット・システムの IP アドレス。

非同期ディスカバリーに使用されるスクリプトは、collation.properties ファイルに定義された TADDM サーバー・プロパティーからの情報を使用し、これらのプロパティーの一部が範囲に指定される場合もあります。

スコープ付きプロパティーIP アドレスまたはスコープ・セット名のいずれかを追加できるプロパティー。 IP アドレスまたはスコープ・セット名を追加すると、プロパティーは、ディスカバーされるホストに依存するようになります。使用できるスコープ・セット名は、スペース、アポストロフィ (')、ピリオド (.)、およびスラッシュ (/) を含まないものに限られます。

何らかの TADDM サーバー・プロパティーを、範囲として指定されるようカスタマイズした場合、makeASDScriptPackage コマンドにIPADDRESS オプションを含める必要があります。

PACKING_METHOD (オプション)ファイルをパッケージ化するために使用する方式。有効な値は tarまたは zip です。

方式が指定されない場合は、オペレーティング・システムによって方式が決まります。例えば、Linux などのオペレーティング・システムの場合、tar 方式が使用されます。

デフォルトでは、システム・パスでアーカイブ・ユーティリティーが検索されます。必要な場合は、com.ibm.cdb.tarpath プロパティーを collation.properties ファイルに追加し、アーカイブ・ユーティリティーを検索する別のパスを指定します。

Solaris オペレーティング・システムでは、ファイル名の長さに制限があるため、gtar アーカイブ・ユーティリティーを使用し、そのユーティリティーへのパスを指定する必要があります。

以下の例は、AIX オペレーティング・システムの場合、TADDM サーバー上の tar コマンドのパスを指定する方法を示しています。

com.ibm.cdb.tarpath=tar

以下の例は、オペレーティング・システムに応じて、ターゲット・システムの tar コマンドのパスを指定する方法を示しています。


AIX の場合com.ibm.cdb.targettarpath.AIX=tar

Solaris の場合com.ibm.cdb.targettarpath.SunOS=/usr/sfw/bin/gtar

例えば、AIX オペレーティング・システム用のディスカバリー・スクリプト・パッケージを生成するには、次のコマンドを入力します。

./makeASDScriptPackage /tmp AIX

このコマンドによって、tmp ディレクトリーに /tmp/taddm_AIX.tar というAIX スクリプト・パッケージが作成されます。

v 拡張方式

makeASDScriptPackage --outputDir OUTPUT_DIR --uname UNAME[--ipAddress IP_ADDRESS] [--packingMethod PACKING_METHOD] [--sensors SENSOR]

--outputDir OUTPUT_DIR通常方式の OUTPUT_DIR パラメーターの説明を参照。

--uname UNAME通常方式の UNAME パラメーターの説明を参照。

[--ipAddress IP_ADDRESS] (オプション)通常方式の IPADDRESS パラメーターの説明を参照。

[--packingMethod PACKING_METHOD] (オプション)通常方式の PACKING_METHOD パラメーターの説明を参照。

[--sensors SENSOR] (オプション)パッケージに含めるセンサーの名前。このコマンドで使用する必要があるセンサー名を以下の表に示します。

表 33. makeASDScriptPackage コマンドで使用されるセンサー名。

センサーコマンドで使用される名前

Apache センサー apacheserver

Citrix XenServer センサー xenserver

FreeBSD コンピューター・システム・センサー

computersystem

汎用サーバー・センサー genericserver

HP NonStop コンピューター・システム・センサー

computersystem

IBM AIX コンピューター・システム・センサー

computersystem

IBM DB2 センサー db2

IBM Lotus® Domino Server センサー dominoserverinitial

IBM Tivoli 使用率センサー utilization

IBM WebSphere MQ サーバー・センサー mqserver

IBM WebSphere センサー webspherescript

JBoss Application Server 7 センサー jboss7

KVM センサー kvm

管理 119

表 33. makeASDScriptPackage コマンドで使用されるセンサー名。 (続き)

センサーコマンドで使用される名前

Linux コンピューター・システム・センサー computersystem

Microsoft Exchange センサー exchange

Microsoft IIS Web サーバー・センサー iisserver

Oracle センサー oracle

Solaris コンピューター・システム・センサー

computersystem

WebLogic SSH センサー weblogiclaunchersensor

Windows コンピューター・システム・センサー

computersystem

非同期ディスカバリー・センサーは、すべてのパッケージにデフォルトで追加されます。すべてのオペレーティング・システム・センサーの名前は computersystem です。これらのセンサーは、--uname パラメーターに基づいて区別されます。例えば、以下のようなパラメーターを指定するとします。

[...] --uname Linux --sensors computersystem

この場合、Linux コンピューター・システム・センサーがパッケージに追加されます。

例えば、AIX オペレーティング・システム用のディスカバリー・スクリプト・パッケージを生成するには、次のコマンドを入力します。

./makeASDScriptPackage --outputDir /tmp --uname AIX --sensors computersystem

このコマンドによって、tmp ディレクトリーに /tmp/taddm_AIX.tar というAIX スクリプト・パッケージが作成されます。

2. スクリプト・パッケージを OUTPUT_DIR からターゲット・システムにコピーし、スクリプト・パッケージを解凍します。

3. UNIX システムでは root ユーザーとして、Windows システムでは管理者として、すべてのスクリプト・ファイルに対する実行特権を付与します。ディスカバリー・スクリプトが非 root ユーザーまたは非管理者ユーザーとして実行された場合、一部のセンサー・スクリプトがディスカバリーを正常に完了しなかったり、センサーがディスカバーするデータが制限されたりする可能性があります。

4. UNIX ターゲットの場合は scriptsRunner.sh スクリプトを実行し、Windowsターゲットの場合は scriptsRunner.bat を実行します。

5. 生成されたアーカイブ・ファイル (例えば /tmp/taddm${version}/asd/taddmasd-${hostname}-${execution timestamp}.tar) を、TADDM サーバー上の、collation.properties ファイル内のcom.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory プロパティーによって定義されたロケーションに移動します。

6. collation.properties ファイルで、com.ibm.cdb.discover.asd.ProcessUnreachableIPs プロパティーの値を trueに設定します。


7. 非同期ディスカバリー・センサー (ASDSensor) が、ディスカバリー・プロファイルで有効になっていることを確認してください。デフォルトでは、このセンサーはレベル 2 およびレベル 3 のディスカバリー・プロファイルで有効になっています。

8. ターゲット・システムの IP アドレスを含むスコープを作成します。

次のタスク

ディスカバリーを実行してください。このディスカバリーの実行に root 権限は必要ありません。

ディスカバリー中に、ping、ポート、またはセッション・センサーがターゲット・システムにアクセスできない場合、ターゲット・システムは到達不能であると判断されます。com.ibm.cdb.discover.asd.ProcessUnreachableIPs プロパティーの値がtrue に設定された場合、そのターゲット・システムのディスカバリー・アーカイブ・ファイルを処理するために非同期ディスカバリー・センサーが実行されます。ディスカバリー・スコープからの IP アドレスが、アーカイブ・ファイルを生成したシステムの IP アドレスに一致する場合のみ、アーカイブ・ファイルが処理されます。アーカイブ・ファイルの内容に基づいて、センサーがスクリプト出力を処理するスケジュールが設定されます。アーカイブ・ファイルが処理されると、ファイルが再度処理されることがないように、その名前が tarfilename.tar_DONE に変更されます。

ディスカバリー・アーカイブ・ファイルが処理されるのは、1 回のみです。アーカイブ・ファイルが処理されるときに、センサーによるスクリプト出力の処理を有効にしていない場合、そのセンサーを有効にして 2 回目のディスカバリーを実行しても、前に処理されたアーカイブ・ファイルは処理されません。ただし、以下のステップを実行した場合は処理されます。

1. アーカイブ・ファイルの名前を元の名前に戻します。例えば、ファイル名から_DONE を削除します。

2. $COLLATION_HOME/var/asdd ディレクトリー内の .processed ファイルには、処理済みのアーカイブ・ファイルのリストが含まれています。 .processed ファイルからアーカイブ・ファイルの名前を削除します。

別々のシステムからの複数のアーカイブ・ファイルを、1 回のディスカバリー実行で処理できますが、1 回のディスカバリー実行では、ターゲット・システムごとにアーカイブ・ファイルは 1 つのみ処理されます。1 つのターゲット・システムに複数のアーカイブ・ファイルがある場合、タイム・スタンプが最新のファイルのみが処理されます。

1 回のディスカバリー実行で別々のシステムからの複数のアーカイブ・ファイルをディスカバーするには、各アーカイブ・ファイルを、com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory プロパティーによって定義されたロケーションにコピーします。ディスカバリー・スコープに、各ターゲット・システムの IP アドレスを含めます。

ディスカバリー・スクリプトが tar コマンドを使用してディスカバリー・アーカイブ・ファイルを作成するため、Windows オペレーティング・システムが稼動している TADDM サーバーを使用している場合、TADDM がアーカイブ・ファイルから

管理 121

ファイルを抽出するために使用するサード・パーティーの tar プログラムをインストールする必要があります。 tar プログラムのロケーションは、com.ibm.cdb.tarpath プロパティーによって定義されます。

制約事項: 使用する tar プログラムでは、長いファイル・パスがサポートされている必要があります。 GNU Tar 1.13 は、長いファイル名を切り詰めることがあるため、サポートされていません。

スクリプト・ベースのディスカバリーの構成スクリプト・ベースのディスカバリーを実行するには、まずディスカバリーを構成する必要があります。


通常のセンサーと比較すると、スクリプト・ベース・モードで実行されるセンサーは、センサーが使用するすべてのコマンドが 1 つのスクリプト内にあり、その内容を確認できるため、より分かりやすくなっています。スクリプト・ベース・モードをサポートするセンサーのリスト、およびいくつかのセンサーに適用される制限については、TADDM の「センサー解説書」のトピック『スクリプト・ベースのディスカバリーと非同期ディスカバリーをサポートするセンサー』を参照してください。

手順

以下のいずれかの方法で、センサーを構成します。

v

スクリプト・ベースのディスカバリーをサポートするすべてのセンサーの有効化スクリプト・ベースのディスカバリーをサポートするすべてのセンサーをグローバルに有効にするには、collation.properties ファイルを開き、com.ibm.cdb.discover.PreferScriptDiscovery プロパティーの値をtrue に設定します。

v

特定のディスカバリー・プロファイル内でのスクリプト・ベースのディスカバリーをサポートするすべてのセンサーの有効化

特定のディスカバリー・プロファイルに対して、スクリプト・ベースのディスカバリーをサポートするすべてのセンサーを有効にするには、以下のステップを実行します。

1. ディスカバリー管理ポータルで、スクリプト・ベース・モードを有効にする対象のディスカバリー・プロファイルを選択します。

2. 「プラットフォーム・プロパティー」タブで、com.ibm.cdb.discover.PreferScriptDiscovery プロパティーの値をtrue に設定します。

v

ディスカバリー・プロファイル内でのスクリプト・ベースのディスカバリーをサポートする 1 つのセンサーの有効化

ディスカバリー・プロファイルで、スクリプト・ベースのディスカバリ


ーをサポートする特定のセンサーを有効にするには、それぞれのディスカバリー・プロファイルでそのセンサーの構成を更新します。以下のステップを実行します。

1. ディスカバリー管理ポータルで、有効にするセンサーが含まれているディスカバリー・プロファイルに移動します。

2. 「センサー構成」タブで、センサーを選択し、「新規」をクリックします。

3. 「構成の作成」ウィンドウで、構成の名前を指定し、「スクリプト・ベースのディスカバリーの実行」オプションを選択します。

4. 「OK」をクリックして、構成を保存します。

次のタスク

ディスカバリーで非デフォルト・ユーザーを選択するための TADDM の構成デフォルトでは、スクリプトで要求されたユーザーのみがディスカバリーで使用されます。デフォルト・ユーザーを使用したディスカバリーの実行で問題が発生し、必要な許可をすべて所有している別のユーザーがある場合は、ディスカバリーでこのユーザーを選択するように TADDM を構成できます。

注: 以下の構成は注意して使用してください。必要な許可を一部しか所有していないか、またはまったく所有していないユーザーがディスカバリーで使用された場合は、ディスカバリーが失敗するか、一部のターゲットがディスカバーされない可能性があります。

COLLATION_HOME/osgi/plugins ディレクトリー内の各センサーのパッケージ内にある plugin.xml ファイルで、以下の IBM WebSphere MQ Server センサーの plugin.xml スニペットのように、script ノード定義を編集します。

<scriptset><ostype>AIX</ostype><mainScript name="sensorCommon.sh" /><script name="script.sh" authClassName="com.collation.platform.security.

auth.MQServerAuth" authMode="preferred" hostAuthFallback="true"/></scriptset>

以下のプロパティーを定義できます。

authModeauthClassName で指定されたタイプのアクセス・リストのエントリーに TADDM がアクセスする方法を定義します。指定可能な値を以下に示します。

v single - スクリプトで要求されたユーザーのみが使用されます。これはデフォルト値です。

v preferred - スクリプトで設定されたユーザーが最初に使用されます。ただし、使用可能でない場合、または失敗した場合は、定義されたタイプの残りのアクセス・リスト・エントリーが使用されます。

v regular - アクセス・リスト・エントリーが指定の順序で使用されます。ユーザー設定は検査されません。

管理 123

hostAuthFallback特定の authClassName または設定済みユーザー (あるいはその両方) のターゲットへの接続の確立時に問題が発生した場合、ターゲットへの接続時に使用された汎用ユーザーによって確立されたセッションに TADDM がフォールバックするかどうかを定義します。指定可能な値を以下に示します。

v false - デフォルト値。

v true。

IBM Tivoli Monitoring (旧方式) を使用したディスカバリーの構成TADDM は、IBM Tivoli Monitoring 6.2.1 以降のインフラストラクチャーを使用してレベル 1、レベル 2、および一部のレベル 3 のディスカバリーを実行できます。

以前の統合方式このセクションでは、TADDM と IBM Tivoli Monitoring の非推奨の統合方式について説明します。TADDM バージョン 7.3.0 以降、IBM TivoliMonitoring 6.3 との統合には、OSLC 自動化を使用することをお勧めします。IBM Tivoli Monitoring スコープ・センサーを使用した古い統合方式は非推奨であり、将来のリリースからは削除される予定です。OSLC 自動化を使用したディスカバリーを実行するための構成について詳しくは、 126 ページの『OSLC 自動化セッションを介したディスカバリーの構成』を参照してください。

IBM Tivoli Monitoring 6.2.1-TIV-ITM-FP0001、6.2.2-TIV-ITM-FP0002、またはそれより後のレベルを使用している場合は、Tivoli Enterprise Portal Server を通じてTivoli Monitoring エンドポイントをディスカバーできます。これらのフィックスパックは、APAR IZ63983 を解決し、それによって TADDM ディスカバリー中のTivoli Monitoring のパフォーマンスを高めます。 IBM Tivoli Monitoring の以前のリリースまたはレベルを使用して Tivoli Enterprise Portal Server から TADDMディスカバリーを実行すると、特に Tivoli Monitoring のコンポーネントで、プロセッサーとネットワークに過剰な負荷がかかるおそれがあります。

注: IBM Tivoli Monitoring を使用してディスカバリーを実行できるのは、TivoliEnterprise Portal Server データベースが Microsoft SQL Server および DB2 上にある場合に限られます。 Apache Derby データベースが Tivoli Enterprise PortalServer データベースとして使用されているときは、これを行うことはできません。

Tivoli Monitoring を使用するディスカバリーに固有の TADDM サーバー・プロパティー

IBM Tivoli Monitoring を使用するディスカバリーに固有の TADDM サーバー・プロパティー (TADDM による Tivoli Monitoring エンドポイントのディスカバー方法に作用するプロパティーを含む) については、 90 ページの『IBM TivoliMonitoring (旧方式) を使用したディスカバリーのプロパティー』を参照してください。

ディスカバリー・プロファイルでは、TADDM による Tivoli Monitoring エンドポイントのディスカバー方法に作用する TADDM サーバー・プロパティーを構成す


ることができます。そのためには、カスタム・プロファイルを使用しているのかデフォルト・プロファイルを使用しているのかに応じて、以下のステップを実行してください。

カスタム・プロファイル用のプロパティーの構成

1. ディスカバリー管理コンソールを開始します。

2. 「ディスカバリー・プロファイル」を開きます。

3. 構成するディスカバリー・プロファイルをクリックします。

4. 「プラットフォーム・プロパティー」タブをクリックします。

5. 更新するプロパティーの値を変更し、このプロパティーに関する「組み込み」チェック・ボックスを選択します。

6. 変更内容を保存します。

デフォルト・プロファイル用のプロパティーの構成$COLLATION_HOME/etc/collation.properties ファイルで、次の例に示すように各プロパティーを追加 (または編集) します。ここで、discovery_profileはプロファイル名を表します。

com.ibm.cdb.session.allow.ITM.discovery_profile=true

例えば次のプロパティーでは、TADDM がディスカバリー・プロファイル「Utilization Discovery」と IBM Tivoli Monitoring を使用して TivoliMonitoring エンドポイントをディスカバーするように指定しています。

com.ibm.cdb.session.allow.ITM.Utilization_Discovery=true

注: collation.properties ファイルでは、プロファイル名の中の「Utilization」と「Discovery」の間のスペース文字を下線文字で置き換える必要があります。

構成を必要とする可能性のある追加 TADDM サーバー・プロパティー

以下の構成ヒントでは、構成を必要とする可能性のある追加 TADDM サーバー・プロパティーについて説明します。

v Windows システムに固有な以下のプロパティーの値は true (これがデフォルト値です) に設定して、IBM Tivoli Monitoring を使用するディスカバリーでWindows ターゲット・システムをディスカバーできるようにする必要があります。この値を false に設定していると、TADDM は Windows ターゲット・システムに対する IBM Tivoli Monitoring セッションを確立できません。

com.collation.AllowPrivateGateways=true

v ディスカバリー中に、Tivoli Enterprise Portal Server でプロセッサーの使用量が増大する場合があります。使用量を最小限に抑えるために、ディスカバリーで実行されるディスカバー・ワーカー・スレッドの数を制限することができます。 TADDM サーバーで、以下のサーバー・プロパティーを設定します。

com.collation.discover.dwcount=16

v 大規模な IBM Tivoli Monitoring 環境では、IBM Tivoli Monitoring スコープ・センサーが完了前にタイムアウトになる場合があります。処理時間を延長するには、以下のサーバー・プロパティーを設定します。

com.collation.platform.session.ITMSessionNumProgressChecks=3600com.collation.discover.agent.ITMScopeSensor.timeout=3600000

管理 125

OSLC 自動化セッションを介したディスカバリーの構成TADDM は、OSLC を使用してレベル 2 のディスカバリーと一部のレベル 3 のディスカバリーを実行できます。

始める前に

OSLC Execute Automation Service Provider が提供するスコープ・セットのディスカバリーを構成するには、以下の要件を満たす必要があります。

v 少なくとも 1 つの OSLC Execute Automation Service Provider がインストールされ、稼働している必要があります。

v TADDM を OSLC Execute Automation Service Provider に接続する必要があります。

手順

OSLC 自動化セッションを介したディスカバリーを実行するには、以下のステップを実行します。

1. 統合先の製品のアクセス資格情報をアクセス・リストに追加します。これを行うには、「統合」>「OSLC 自動化」タイプの新しいアクセス・リスト・エントリーを作成します。 TADDM を ITM に統合する場合は、ITM TEPS の資格情報を指定します。ディスカバリー時に、以前のバージョンとの互換性を確保するために、OSLC 自動化のアクセス・リスト・エントリーと ITM のアクセス・リスト・エントリー・タイプが使用されます。

2. ディスカバリー・スコープを確認します。スコープ・セットは、OSLCAutomationAgent によって定期的に作成されます。新しいスコープ・セットは、「スコープ・セット」タブにリストされます。 TADDM を ITM に統合する場合は、ITM TEMS ごとに 1 つのスコープ・セットが作成されます。OSLCAutomationAgent を手動で実行するには、以下のコマンドを使用します。

/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent

3. OSLC 自動化セッションの使用を許可するディスカバリー・プロパティーを構成します。このプロパティーは、collation.properties ファイルで設定することも、新しいカスタム・ディスカバリー・プロファイルで設定することもできます。

v collation.properties ファイルの場合:

com.ibm.cdb.session.prefer.OSLCAutomation=truecom.ibm.cdb.session.allow.OSLCAutomation=true

スコープ付きプロパティーの例:

com.ibm.cdb.session.prefer.OSLCAutomation.9.222.222.124=falsecom.ibm.cdb.session.prefer.OSLCAutomation.Level_3_Discovery=false

v カスタム・ディスカバリー・プロファイル。ディスカバリー管理コンソールで、新しいディスカバリー・プロファイルを作成し、以下のように「プラットフォーム・プロパティー」タブを構成します。

com.ibm.cdb.session.allow.OSLCAutomation=truecom.ibm.cdb.session.prefer.OSLCAutomation=true

4. 以下のいずれかの方法を選択し、OSLCAutomationAgent が作成したスコープに対して通常のディスカバリーを実行します。


v デフォルトの L2 または L3 プロファイル (OSLCAutomation セッションをサポートするように collation.properties ファイルが構成されている場合)。

v 「プラットフォーム・プロパティー」タブが適切に構成された新しいディスカバリー・プロファイル。

関連資料:

93 ページの『OSLC 自動化セッションを使用したディスカバリーのプロパティー』これらのプロパティーは、OSLC 自動化セッションを使用したディスカバリーに適用されます。

233 ページの『OSLCAutomationAgent のコマンド行インターフェース』OSLCAutomationAgent は、OSLC Execute Automation Service Provider からデータを収集するために使用されます。これらのコマンドを使用して、エージェントの手動での実行と、作成されたスコープ・セットのリフレッシュや更新を行うことができます。

ディスカバリーのレベルの構成ディスカバリーのレベルは、構成する必要があります。

レベル 1 ディスカバリーの構成レベル 1 ディスカバリー (資格情報不足ディスカバリー) にはある一定の最小構成が必要とされ、このディスカバリーでは TCP/IP スタックをスキャンして、アクティブ・コンピューター・システムに関する基本情報を収集します。


レベル 1 ディスカバリーでは、ご使用の環境で TADDM サーバーにディスカバーさせるネットワーク・デバイスを構成する必要があります。

手順

これを行うには、以下のステップを実行します。

1. ご使用の SNMP バージョンに応じて、 TADDM サーバーで使用する以下の情報を記録します。

v SNMP V1 および V2 の場合、SNMP MIB2 GET COMMUNITY ストリングを記録します。

v SNMP V3 の場合、SNMP ユーザー名およびパスワードを記録します。

2. MIB2 の System、IP、Interfaces、および Extended Interfaces に対する許可を割り当てます。

レベル 2 ディスカバリーの構成レベル 1 ディスカバリーの要件に加えて、レベル 2 ディスカバリーには、詳細なホスト構成情報のディスカバリーをサポートするための構成が必要です。

管理 127

始める前に

ターゲット・システムが、IBM Tivoli Monitoring スコープ・センサーによってディスカバーされた IBM Tivoli Monitoring エンドポイントの場合、これらのターゲット・システムの資格情報はレベル 2 ディスカバリーには必要ありません。詳細は、次のソースを参照してください。

v 235 ページの『TADDM と IBM Tivoli Monitoring (旧方式) との統合』

v 124 ページの『IBM Tivoli Monitoring (旧方式) を使用したディスカバリーの構成』

v IBM Tivoli Monitoring スコープ・センサーに関する情報が記載された TADDMの「センサー解説書」


TADDM によるディスカバーを実行するターゲット・オペレーティング・システム(コンピューター・システム) に対し、最低でも以下のソフトウェアを構成する必要があります。

Secure Shell (SSH)OpenSSH、またはオペレーティング・システムに付属するベンダー提供バージョンの SSH を使用できます。Windows オペレーティング・システムについて詳しくは、 144 ページの『Windows ManagementInstrumentation (WMI) 依存関係』を参照してください。

SUNWscpu (Solaris 環境のみ)プロセスに関する完全な情報を提供するには、SUNWscpu (SourceCompatibility) パッケージをインストールします。

LiSt Open Files (lsof)依存関係に関する完全な情報を提供するには、https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/TADDM%20lsof%20requirements の TADDM Wiki にある lsof requirements の要件に従って、LiSt Open Files (lsof) プログラムをインストールします。

サービス・アカウントの作成:

SSH 鍵ベースおよびパスワード・ベースの接続を使用してディスカバーされるすべてのコンピューター・システム上で、サービス・アカウントを作成する必要があります。これは、ネットワーク内のコンピューター・システム (サーバー) をディスカバーするための主要な方法です。


ディスカバリーのセットアップを簡略化するには、ディスカバー対象の各ターゲット・コンピューター・システム上に、同一のサービス・アカウントを作成します。このサービス・アカウントでは、TADDM がディスカバーする必要のあるターゲット・コンピューター・システム上のすべてのリソースへのアクセスを許可する必要があります。サービス・アカウントは、各ターゲット・コンピューター・システム上のホーム・ディレクトリーへの書き込みアクセス権限を持っていなければなりません。このディレクトリーには、およそ 20 MB のフリー・スペースが必要です。


https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/TADDM%20lsof%20requirements




ディスカバリー中に、スクリプトおよび一時結果ファイルをこのディレクトリーに保管することができます。ディスカバリーの実行後、それらのファイルは削除されます。

非 root 特権を備えたサービス・アカウントを使用することが可能です。ただし、ターゲット・コンピューター・システム上で実行するためには、ディスカバリー中に使用される一部のオペレーティング・システム・コマンドでは root (またはスーパーユーザー) 権限といった上位の特権を必要とする場合があります。

手順

ターゲット・コンピューター・システム上でサービス・アカウントを作成するには、以下のいずれかの手順を実行します。

1. Linux、Solaris、AIX、および Linux for System z オペレーティング・システムの場合は、サービス・アカウント名が coll であることを想定し、以下のコマンドを使用してサービス・アカウントを作成します。

# mkdir -p /export/home/coll# useradd -d /export/home/coll -s /bin/sh ¥

-c "Service Account" -m coll# chown -R coll /export/home/coll

2. Windows コンピューター・システムには、ローカル管理者のグループのメンバーであるサービス・アカウントを作成します。このアカウントは、ローカル・アカウントにすることも、ドメイン・アカウントにすることもできます。TADDM は、WMI を使用してディスカバリーを行います。そのため、アカウントには、ローカル・コンピューター上のすべての WMI オブジェクトへのアクセス権限が必要です。サービス・アカウントは、Windows ゲートウェイおよびすべてのターゲット Windows コンピューター・システムで作成する必要があります。

注: サービス・アカウントは、¥WINDOWS¥system32 または ¥WINDOWS¥system64ディレクトリーおよびそのサブディレクトリーへの読み取り/書き込み権限を持っていなければなりません。 WindowsServer 2008 システムでは、新規ユーザーはデフォルトでは必要なアクセス権限を持たないため、サービス・アカウントのアクセス権限を明示的に付与する必要があります。

セキュア・シェル (SSH) を使用するディスカバリー用の構成:

TADDM サーバーは、OpenSSH (バージョン 1 または 2) に接続することも、オペレーティング・システムに付属するベンダー提供バージョンの SSH に接続することもできます。

TADDM サーバーでは、以下の認証方式がサポートされています。

v SSH2 鍵ベース・ログイン (RSA 鍵または DSA 鍵) および SSH1 鍵ベース・ログイン (RSA のみ)

v SSH2 を使用したユーザー名とパスワード、および SSH1 を使用したユーザー名とパスワード

すべての認証方式が使用できますが、SSH2 鍵ベース・ログインの使用が推奨されています。サーバーは、事前にリストされている順序でそれぞれのメソッドを自動

管理 129

的に試行し、正常に作動する最初のメソッドを使用します。TADDM サーバーは、ディスカバリーの全実行中、そのホストに対して同じメソッドを使用します。

注: SSH2 鍵ベース・ログインの場合、TADDM サーバーは、TADDM サーバーで見つかった 1 つの鍵 (RSA または DSA) だけを使用して、ログインを試みます。両方の鍵が存在する場合、RSA だけが使用されます。

TADDM サーバーで鍵ベース・ログインを行うための鍵ペアの作成:

セキュア・シェル・プロトコル (SSH) を使用することで、TADDM サーバーで鍵ベース・ログインを行うための公開鍵/秘密鍵ペアを作成できます。


使用する SSH のバージョンに応じて、SSH 鍵ベース・ログインでは表 34 に示す鍵が使用されます。

表 34. SSH 鍵

SSH バージョン/アルゴリズム秘密鍵公開鍵

Openssh/SSH2/RSA $HOME/.ssh/id_rsa $HOME/.ssh/id_rsa.pub

Openssh/SSH2/DSA $HOME/.ssh/id_dsa $HOME/.ssh/id_dsa.pub

Openssh/SSH1/RSA $HOME/.ssh/identity $HOME/.ssh/identity.pub

Commercial/SSH2/RSA $HOME/.ssh2/id_dss_1024_a $HOME/.ssh2/id_dss_1024_a

.pub

公開鍵/秘密鍵ペアは、OpenSSH バージョン 2 を使用して生成することもできます。 OpenSSH 以外の SSH プログラム、または別のバージョンの OpenSSH を使用して公開鍵/秘密鍵ペアを生成するには、 SSH の資料を参照してください。

手順

OpenSSH バージョン 2 を使用して公開鍵/秘密鍵ペアを生成するには、以下のステップを実行します。

1. TADDM サーバーの所有者としてログインします。

2. SSH 鍵を生成するには、次のコマンドを入力します。

$ ssh-keygen -t rsa

コマンドのデフォルトを受け入れます。 TADDM は、パスフレーズ付きの鍵ペアもパスフレーズなしの鍵ペアもサポートします。

3. 鍵ベース・ログインを許可する各ターゲット・コンピューター・システム上で、サービス・アカウントに対して、id_rsa.pub ファイルの内容を$HOME/.ssh/authorized_keys ファイルに挿入します。特定の SSH2 インプリメンテーションでは、$HOME/.ssh 以外のディレクトリーに鍵が生成されます。ユーザーの SSH インプリメンテーションで、異なるディレクトリーに、または異なる名前で鍵が生成される場合、その秘密鍵ファイルをアルゴリズムに応じて$HOME/.ssh/id_rsa または $HOME/.ssh/id_dsa ディレクトリーにコピー、リンク、または移動します。


コンピューター・システム・サービス・アカウント用のアクセス・リスト・エントリーの追加:

セキュア・シェル (SSH) によるパスワード認証を構成するには、ターゲット・システムで作成したコンピューター・システム・サービス・アカウント用のアクセス・リスト・エントリーを追加する必要があります。

コンピューター・システム・サービス・アカウント用のアクセス・リスト・エントリーを追加するには、以下のステップを実行します。

1. TADDM の開始ページから、アドミニストレーター・コンソール内のすべてのサービスが開始済みであることを確認します。

2. ディスカバリー管理コンソールを開始します。

3. 「セキュア (SSL) セッションを確立」チェック・ボックスを選択して、SSL セキュリティー・オプションを使用できるようにします。このオプションでは、アクセス・リストのユーザー名とパスワードを含むすべてのデータが暗号化されてから、ディスカバリー管理コンソールと TADDM サーバー間でそのデータが送信されます。

4. サービス・アカウント用のコンピューター・システム・アクセス・リスト・エントリーを追加し、ログイン名およびパスワードを指定します。

System p および System i の構成:

IBM Power5 テクノロジー・ベースのシステム (System p または System i®) およびその論理区画のディスカバリーは、管理コンソールを介して実行されます。TADDM では、Hardware Management Console (HMC) および IntegratedVirtualization Manager (IVM) という 2 種類の管理コンソールがサポートされています。

TADDM では、SSH を使用して管理コンソールをディスカバーします。ディスカバリーのスコープには管理コンソールの IP アドレスを含める必要があり、アクセス・リストには適切な資格情報 (ユーザー名およびパスワード) を指定して「コンピューター・システム」タイプの項目を含める必要があります。

ユーザー資格情報に加えて、ディスカバリー・ユーザーを、以下に示す最小限のアクセス権を指定して、管理コンソールで定義する必要があります。

v Hardware Management Console (HMC)

– HMC 管理コンソールでは、hmcoperator 役割に基づくユーザーが必要です。例えば、hmcoperator 役割に基づく taddmViewOnly という役割を新規に作成します。また、次に示すコマンド行タスクをこの新しい役割に割り当てる必要があります。

管理対象システムlshwres コマンドおよび lssyscfg コマンドを使用する場合に必要です。

論理区画lshwres コマンド、lssyscfg コマンド、および viosvrcmd コマンドを使用する場合に必要です。

管理 131

HMC 構成lshmc コマンドを使用する場合に必要です。

v Integrated Virtualization Manager (IVM)

IVM 管理コンソールでは、View Only 役割のユーザーが必要です。

レベル 3 ディスカバリーの構成レベル 2 ディスカバリーの要件に加えて、レベル 3 ディスカバリーには、アプリケーション構成およびホスト・データのディスカバリーをサポートするための構成が必要です。

ディスカバリー用 Web サーバーおよびアプリケーション・サーバーの構成:

TADDM サーバーでディスカバーする、環境内の Web サーバーおよびアプリケーション・サーバーを構成する必要があります。

このセクションでは、Web サーバーおよびアプリケーション・サーバーを構成するための手順について説明します。

Microsoft IIS サーバーの場合は、構成の必要はありません。特殊なアクセス権は不要です。ホスト上で設定済みのユーザー・アカウントで十分です。

Apache Web server の場合は、ホスト・システムの TADDM サービス・アカウントに、Apache 構成ファイル (httpd.conf ファイルなど) に対する読み取り権限がなければなりません。

Oracle iPlanet Web server の場合は、ホスト・システムの TADDM サービス・アカウントに、iPlanet 構成ファイルに対する読み取り権限がなければなりません。

IBM Lotus Domino Server の場合は、TADDM の「センサー解説書」の『IBMLotus Domino Server センサー』トピックに記載されている前提条件を満たしていることを確認してください。

Oracle Application Server の構成:

Oracle Application Server のディスカバリーは、Oracle Application Server に組み込まれている JAR ファイルを使用します。これらの JAR ファイルは、TADDMサーバー・インストールには組み込まれていません。


$COLLATION_HOME/etc/collation.properties ファイルには、既存の OracleApplication Server インストール済み環境を指すためのプロパティーがあります。$COLLATION_HOME/etc/collation.properties ファイル内に以下のテキストがあります。

# Location of the root directory for Oracle Application Server onthe Tivoli Application Dependency Discovery Managerサーバー# 1. An example is /home/oracle/product/10.1.3/OracleAS_1# 2. A relative directory is relative to com.collation.home# 3. This directory (and its subdirectories) must be accessible

for the user under which the server runs, usually the collation user.# 4. Ignore if you do not intend to discover an Oracle Application server.


既存の Oracle Application Server インストール済み環境を指すには、$COLLATION_HOME /etc/collation.properties ファイルで以下の行を編集します。

com.collation.oracleapp.root.dir=lib/oracleapp

Oracle Application Server のインストールでは、必要な JAR ファイルを含んでいるディレクトリーは、rwx------ 許可を持つ oracle ユーザーによって所有されています。これは、所有者 (通常は Oracle アプリケーション) 以外のユーザーが、これらのディレクトリーにアクセスできないことを意味しています。 TADDM サーバーが oracle ユーザーを使用して実行中の場合、これらのディレクトリーはアクセス可能です。しかし、そうでない場合は、以下のディレクトリーのディレクトリー許可を 711 に変更する必要があります。これで、すべてのユーザーがこれらのディレクトリーにアクセスできます。

v OracleAppServerHome

v OracleAppServerHome/j2ee

v OracleAppServerHome/j2ee/home

v OracleAppServerHome/opmn

v OracleAppServerHome/opmn/lib。OracleAppServerHome の例は/home/oracle/product/10.1.3/OracleAS_1 です。

Oracle Application Server のディスカバリーの場合、$COLLATION_HOME/etc/

collation.properties ファイル内のcom.collation.platform.os.ignoreLoopbackProcesses プロパティーを true に設定する必要があります。

com.collation.platform.os.ignoreLoopbackProcesses=true

手順

アクセス・リストを構成するには、以下のステップを実行します。

1. ディスカバリー管理コンソールから、ご使用の Oracle Application Server を含むディスカバリー・スコープ・セットを作成するか、ご使用の OracleApplication Server を含む既存のスコープを使用します。

2. アクセス・リストを作成するには、「アクセス・リスト」アイコンをクリックします。

3. 「アクセス・リスト」ウィンドウで「追加」をクリックします。

4. 「アクセスの詳細」ウィンドウの「コンポーネント・タイプ」フィールドで、「アプリケーション・サーバー」をクリックします。

5. 「ベンダー」フィールドで、「Oracle Application Server」をクリックします。

6. Oracle Application Server の資格情報を入力します。

Microsoft Exchange Server の構成:

TADDM サーバーでディスカバーする、Microsoft Exchange サーバーを構成する必要があります。

管理 133


Microsoft Exchange Server をディスカバーするには、Microsoft ExchangeManagement サービスがターゲット Windows システムで稼働していなければなりません。 Microsoft Exchange Server が稼働する Windows システムで、TADDMサービス・アカウントの Windows サービス ID を作成しておく必要があります。この Windows サービス ID には、以下の WMI ネーム・スペースへのフル・アクセス権限 (メソッドの実行、完全な書き込み、部分的書き込み、プロバイダーによる書き込み、アカウントの有効化、リモートの有効化、セキュリティーの読み取り、セキュリティーの編集) が必要です。

v Root¥CIMV2

v Root¥CIMV2¥Applications¥Exchange

v Root¥MicrosoftExchangeV2

TADDM サービス・アカウントの Windows サービス ID に Microsoft Exchangeserver をディスカバーできるだけの十分な許可がある場合、センサーはこのWindows サービス ID を使用するので、個々の Microsoft Exchange Server アクセス・リスト項目は不要です。

TADDM サービス・アカウントの Windows サービス ID に Microsoft ExchangeServer をディスカバーできるだけの十分な許可がない場合は、以下のステップを実行して、個々の Microsoft Exchange Server アクセス・リストを作成する必要があります。

手順

アクセス・リストを構成するには、以下のステップを実行します。

1. ディスカバリー管理コンソールから、ご使用の Microsoft Exchange Server を含むディスカバリー・スコープ・セットを作成するか、ご使用の MicrosoftExchange Server を含む既存のスコープを使用します。

2. アクセス・リストを作成するには、「アクセス・リスト」アイコンをクリックします。

3. 「アクセス・リスト」ウィンドウで「追加」をクリックします。

4. 「アクセスの詳細」ウィンドウの「コンポーネント・タイプ」フィールドで、「メッセージング・サーバー」をクリックします。

5. 「ベンダー」フィールドで、「Microsoft Exchange Server」をクリックします。

6. Microsoft Exchange Server の資格情報を入力します。

VMware サーバーの構成:

TADDM ディスカバリー・プロセスは、正しく構成されている場合は、 VMwareサーバーに関する情報を戻します。


VMware サーバーをディスカバリー用に構成するには、非 root TADDM サービス・アカウントの読み取り専用権限を VMware ESX コンソールで設定します。代わりの方法として、root ユーザーをディスカバリー用に使用することも可能です。


VMware サーバーの詳細については、 https://communities.vmware.com/welcome にある VMware のコミュニティーでトピックを検索できます。

ディスカバリーのためのデータベースのセットアップ:

データベースのディスカバリーをサポートするためには、TADDM サーバーのDB2、Oracle、または Sybase データベース・ユーザーを作成する必要があります。 TADDM サーバーでは、これらのデータベース・ユーザーにより、リモート・ホスト上で動作しているデータベースに関する情報が収集されます。

DB2 ユーザーの作成:

DB2 インスタンスをリモート・コンピューター・ホスト上で完全にディスカバーするために、DB2 ユーザーを作成します。

手順

DB2 ユーザーを作成するには、以下のステップを実行します。

1. 以下のアイテムへのアクセス権限が付与されたユーザーを作成します。

v DB2 データベース TADDM サーバー

v ディスカバーする必要がある DB2 データベース TADDM サーバー内のすべてのインスタンス

2. DB2 データベース・サーバーをホストするシステムに対する SSH アクセス権限を持つように、この DB2 ユーザーを構成します。

3. 以下の手順を実行して、TADDM サーバーのアクセス・リストに DB2 ユーザーのユーザー名およびパスワードを追加します。

a. ディスカバリー管理コンソールのツールバーで、「ディスカバリー」 >「アクセス・リスト」をクリックします。「アクセス・リスト」ペインが表示されます。

b. 「追加」をクリックします。「アクセスの詳細」ウィンドウが表示されます。

c. 「アクセスの詳細」ウィンドウで、以下の情報を入力します。

1) 「コンポーネント・タイプ」リストで、「データベース」を選択します。

2) 「ベンダー」リストで、「DB2」を選択します。

3) DB2 ユーザーの「名前」、「ユーザー名」、および「パスワード」を入力します。

d. 「OK」をクリックして情報を保管します。「アクセス・リスト」ペインに新規の情報が表示されます。

Microsoft SQL Server ユーザーの作成:

Microsoft SQL Server インスタンスをリモート・コンピューター・ホスト上で完全にディスカバーするために、 Microsoft SQL Server ユーザーを作成します。

手順

Microsoft SQL Server ユーザーを作成するには、以下のステップを実行します。

管理 135

https://communities.vmware.com/welcome

https://communities.vmware.com/welcome

1. Microsoft SQL Server ユーザーを db_datareader 役割特権およびVIEW_ANY_DEFINITION 許可で作成します。これは、場合によっては MicrosoftSQL Server 管理者が行う必要があります。

2. ディスカバリー管理コンソールで以下のステップを実行し、Microsoft SQLServer ユーザーのユーザー名とパスワードを TADDM サーバーのアクセス・リストに追加します。

a. ツールバーで、「ディスカバリー」 > 「アクセス・リスト」をクリックします。「アクセス・リスト」ペインが表示されます。




2) 「ベンダー」リストで、「Microsoft SQL Server」を選択します。

3) 「名前」、「ユーザー名」、および「パスワード」を入力します。


Oracle ユーザーの作成:

Oracle インスタンスをリモート・コンピューター・ホスト上で完全にディスカバーするために、Oracle ユーザーを作成します。

手順

Oracle ユーザーを作成するには、以下のステップを実行します。

1. SELECT_CATALOG_ROLE 特権を持つ Oracle ユーザーを作成します。この作業は、場合によっては Oracle 管理者が行う必要があります。

例えば、次のコマンドを使用して IBM Oracle ユーザーを作成します。

create user collation identified by collpassword;grant connect, select_catalog_role to collation;

2. ディスカバリー管理コンソールで以下のステップを実行し、Oracle ユーザーのユーザー名とパスワードを TADDM サーバーのアクセス・リストに追加します。

a. ツールバーで、「ディスカバリー」 > 「アクセス・リスト」をクリックします。「アクセス・リスト」ペインが表示されます。




2) 「ベンダー」リストで、「Oracle」を選択します。

3) コンピューターの「名前」、「ユーザー名」、および「パスワード」を入力します。



Sybase ユーザーの作成:

リモート・コンピューター・ホスト上で Sybase ASE を完全にディスカバーするために、適切な役割に割り当てられた Sybase ユーザーを作成します。

手順

Sybase ユーザーを作成するには、以下のステップを実行します。

1. 以下のコマンドを使用して、sa-role のメンバーである Sybase ユーザーを作成します。

sp_role "grant",sa_role,IBM

Sybase IQ ユーザーが DBA のメンバーになっていることを確認します。Sybase IQ ユーザーが DBA のメンバーではない場合、Sybase IQ データベース固有情報は検出できません。

2. ディスカバリー管理コンソールで以下のステップを実行し、Sybase ユーザーのユーザー名とパスワードを TADDM サーバーのアクセス・リストに追加します。

a. アクセス・リストを作成するには、「アクセス・リスト」アイコンをクリックします。

b. 「アクセス・リスト」ウィンドウで「追加」をクリックします。

c. 「アクセスの詳細」ウィンドウの「コンポーネント・タイプ」フィールドで、「データベース」をクリックします。

d. 「ベンダー」フィールドで、「データベース」をクリックします。

e. 資格情報 (ユーザー名およびパスワード) を入力して、Sybase サーバーへのJava Database Connectivity (JDBC) を確立します。

Windows システムのディスカバリーの構成Windows コンピューター・システムのディスカバリーの場合、TADDM は、非同期ディスカバリーとスクリプト・ベースのディスカバリーの他に、ゲートウェイ・ベースのディスカバリーと SSH ベースのディスカバリーの両方をサポートしています。

非同期ディスカバリーについて詳しくは、 117 ページの『非同期ディスカバリーの構成』を参照してください。スクリプト・ベースのディスカバリーについて詳しくは、 122 ページの『スクリプト・ベースのディスカバリーの構成』を参照してください。

ゲートウェイ・ベースのディスカバリーでは、SSH を通じてアクセス可能であり、ゲートウェイとして機能する、専用の Windows コンピューター・システムが必要です。すべてのディスカバリー要求は、ゲートウェイを通過します。ゲートウェイは、Windows Management Instrumentation (WMI) を使用して、ターゲットのWindows コンピューター・システムをディスカバーします。

管理 137

Fix Pack 2 TADDM 7.3.0.2 以降を使用する場合、WMI の代わりに PowerShell セッションを使用して、ターゲットの Windows コンピューター・システムをディスカバーすることもできます。PowerShell セッションを使用した通信のみを許可するように TADDM を構成できます。詳しくは、TADDM の「ユーザーズ・ガイド」の『アンカーのないファイアウォールを通過するディスカバリーの構成』トピックを参照してください。

SSH ベースのディスカバリーでは、専用のゲートウェイ・コンピューター・システムは必要ありません。その代わりに、ディスカバリーは、ターゲットの Windowsコンピューター・システムへの直接 SSH 接続を使用します。

一般に、ゲートウェイ・ベースのディスカバリーの方が SSH ベースのディスカバリーよりも好んで用いられます。これは、SSH の構成よりゲートウェイおよびWMI または PowerShell の構成の方が容易であるためです。TADDM によってサポートされているすべての Windows ターゲット・システムで、WMI がデフォルトで使用可能になっています。PowerShell は、Windows Server 2008 以降が稼働しているターゲットでのみサポートされます。ゲートウェイ・システムおよびターゲット・システムに PowerShell バージョン 2 以降がインストールされている必要があります。(SSH サーバーを必要とする) ゲートウェイ・コンピューター以外では、Windows ターゲットに関する特別なソフトウェア要件はありません。ただし、ディスカバリー・フローにゲートウェイが関与しないことと、WMI プロバイダーがデプロイされないことから、SSH を使用するディスカバリーの方が高速になる可能性があります。

ダイレクト・ディスカバリーを実行するには、各 Windows ターゲット・システムに SSH サーバーが必要です。また、SSH を使用した直接ディスカバリーの場合は、Microsoft .NET Framework バージョン 2 または 3 を各 Windows ターゲット・システムにインストールする必要があります。.NET Framework は、デフォルトでは Windows Server 2000 にインストールされません。

注: Fix Pack 2 TADDM 7.3.0.2 以降を使用する場合、.NET Framework バージョン 4 または 4.5 をインストールすることもできます。

この両方の種類のディスカバリーでは、ディスカバリーを実行するために TADDMWindows ディスカバリー・プログラム (TaddmTool.exe ファイル) が使用されます。ゲートウェイを使用するディスカバリーの場合、TaddmTool プログラムは、ディスカバリーの初期設定時にゲートウェイにデプロイされます。 SSH を使用するディスカバリーの場合、TaddmTool プログラムは、各 Windows ターゲット・コンピューター・システムにデプロイされます。 TaddmTool プログラムは、.NETアプリケーションです。

デフォルトでは、TADDM はゲートウェイ・ベースのディスカバリーのみを使用するように構成されます。この構成は、以下の 2 つの TADDM サーバー・プロパティーによって制御されます。これらのプロパティーについては、Windows コンピューター・システム・センサー用の TADDM の「センサー解説書」で説明されています

v com.collation.AllowPrivateGateways=true

v com.collation.PreferWindowsSshOverGateway=false


デフォルトでは、TADDM は WMI セッションを使用するように構成されます。PowerShell セッションを使用する状況、および使用可能にする方法については、145 ページの『PowerShell セッション』を参照してください。

WMI による Windows ゲートウェイを使用しても、SSH による直接接続を使用しても、取り出される情報は同一です。以下のリストに、ゲートウェイ・ベースおよび SSH ベースのディスカバリーの前提条件を示します。

WMI を使用したゲートウェイ・ベースのディスカバリーの前提条件

1. ゲートウェイとして機能する専用の Windows Server コンピューター・システムが必要です。ゲートウェイ・サーバーのオペレーティング・システム要件は、TADDM サーバーの Windows オペレーティング・システム要件と同じです。サポートされる Windows オペレーティング・システムについて詳しくは、TADDM の「インストール・ガイド」の『TADDM サーバーのソフトウェア要件』トピックを参照してください。

2. ゲートウェイは、ディスカバー対象の Windows コンピューターと同じファイアウォール・ゾーンにある必要があります。

3. サポートされているバージョンの SSH サーバーをゲートウェイ・コンピューター・システムにインストールする必要があります。

4. ゲートウェイは、各 Windows ターゲットをディスカバーするために、リモート WMI を使用します。さらに、ディスカバリーの初期設定時には、WMI プロバイダーが各 Windows ターゲット・コンピューター・システムに自動的にデプロイされます。 WMI プロバイダーは、コアWMI に組み込まれていないデータをディスカバーするために使用します。ディスカバーする Windows ターゲット・コンピューター・システム上の WMI を使用可能に設定します。デフォルトでは、Windows2000 以降の大半のシステムで WMI が使用可能になっています。

Fix Pack 2

PowerShell を使用したゲートウェイ・ベースのディスカバリーの前提

条件

1. ゲートウェイとして機能する専用の Windows Server コンピューター・システムが必要です。ゲートウェイ・サーバーのオペレーティング・システム要件は、TADDM サーバーの Windows オペレーティング・システム要件と同じです。サポートされる Windows オペレーティング・システムについて詳しくは、TADDM の「インストール・ガイド」の『TADDM サーバーのソフトウェア要件』トピックを参照してください。

2. ゲートウェイ・システムおよびターゲット・システムに PowerShell バージョン 2 以降をインストールする必要があります。Windows Server2008 以降が稼働しているターゲットのみサポートされます。

3. 次のコマンドを実行して、ゲートウェイを構成する必要があります。

Set-Item WSMan:¥localhost¥Client¥TrustedHosts * -Force

このコマンドは、trustedHosts リストを設定します。デフォルトでは、このリストは存在しますが、空の状態であるため、リモート・セッションが開かれる前にリストを設定しておく必要があります。-Force パラ

管理 139

メーターを使用することにより、PowerShell はステップごとにプロンプトを出さずにコマンドを実行します。

4. 次のコマンドを実行して、ターゲット・システムを構成する必要があります。

Enable-PSRemoting -Force

このコマンドは、WinRM サービスを開始し、このサービスがシステムで自動的に開始されるように設定し、着信接続を許可するためのファイアウォール・ルールを作成します。-Force パラメーターを使用することにより、PowerShell はステップごとにプロンプトを出さずにこれらのアクションを実行します。

SSH ベースのディスカバリーの前提条件

1. サポートされているバージョンの SSH サーバーを各 Windows ターゲット・システムにインストールする必要があります。

2. Microsoft .NET Framework バージョン 2 または 3 を各 WindowsServer ターゲット・システムにインストールする必要があります。

注: Fix Pack 2 TADDM 7.3.0.2 以降を使用する場合、.NET Frameworkバージョン 4 または 4.5 をインストールすることもできます。

TADDM の「センサー解説書」の『非管理 Windows ディスカバリーの構成』トピックも参照してください。

Bitvise WinSSHD の構成Bitvise WinSSHD を使用して、Windows システムへの SSH アクセスが可能です。

始める前に

ゲートウェイ・ベースのディスカバリーの場合、ゲートウェイ・システムに BitviseWinSSHD をインストールする必要があります。ダイレクト SSH ディスカバリーの場合、各 Windows システムに Bitvise WinSSHD をインストールする必要があります。

サポートされる Bitvise WinSSHD のバージョンについて詳しくは、TADDM の「インストール・ガイド」の『Windows ゲートウェイ』トピックを参照してください。

Bitvise WinSSHD は http://www.bitvise.com/ から入手できます。


Bitvise WinSSHD 5.22 の構成方法を以下の手順で説明します。ご使用の BitviseWinSSHD のリリースによって、特定の手順は異なる場合があります。

手順

1. SSH ホストの TADDM サーバーに対するアクセスを制限するには、以下の手順を実行します。


http://www.bitvise.com/

a. WinSSHD 制御パネルで、「簡易設定を開く (Open easy settings)」をクリックします。

b. 「サーバー設定」タブの「Windows ファイアウォールを開く (OpenWindows Firewall)」フィールドで、「詳細 WinSSHD 設定での設定に基づく (As set in Advanced WinSSHD settings)」を選択します。

c. 「変更の保存」をクリックします。

d. WinSSHD 制御パネルで、「詳細設定の編集 (Edit advanced settings)」をクリックします。「詳細 WinSSDH 設定 (Advanced WinSSDHSettings)」ウィンドウが表示されます。

e. 「設定」 > 「セッション」をクリックします。

f. 以下の項目の値を 0 に設定します。

v 「IP ブロッキング (IP blocking)」- ウィンドウ期間

v 「IP ブロッキング (IP blocking)」- ロックアウト時間

g. 「OK」をクリックします。

h. WinSSHD 制御パネルで、「詳細設定の編集 (Edit advanced settings)」をクリックします。「詳細 WinSSDH 設定 (Advanced WinSSDHSettings)」ウィンドウが表示されます。

i. 「設定」 > 「アクセス・コントロール」をクリックします。

j. 右のペインで、「IP 規則 (IP rules)」をクリックします。

k. 「追加」をクリックします。

l. TADDM サーバーの IP アドレスを入力します。

m. 「有効ビット数 (Number of significant bits)」フィールドに、32 と入力します。

n. 「説明」フィールドに、TADDM server と入力します。

o. 「接続の許可 (Allow connect)」チェック・ボックスが選択されていることを確認します。

p. 「OK」をクリックします。

q. リストからエントリー 0.0.0.0/0 を削除します。

2. 仮想グループおよびユーザーを作成して構成するには、以下の手順を実行します。

a. WinSSHD 制御パネルで、「詳細設定の編集 (Edit advanced settings)」をクリックします。「詳細 WinSSDH 設定 (Advanced WinSSDHSettings)」ウィンドウが表示されます。

b. 「設定」 > 「仮想グループ」をクリックします。

c. 新規グループを追加するには、「追加」をクリックします。

d. 「グループ」および「Windows アカウント名」フィールドに、名前を入力します。

e. 「OK」をクリックします。

f. 「設定」 > 「仮想アカウント」をクリックします。

g. 新規アカウントを追加するには、「追加」をクリックします。

h. 「仮想アカウント名」フィールドに名前を入力します。

i. 仮想アカウント・パスワードのリンクを使用してパスワードを設定します。

管理 141

j. ドロップダウン・リストから前の手順で作成した仮想グループを選択し、「グループのデフォルト Windows アカウントを使用 (Use group defaultWindows account)」チェック・ボックスが選択されていることを確認します。

k. 「OK」をクリックします。

3. WinSSHD 制御パネルで、「WinSSHD の開始 (Start WinSSHD)」をクリックします。

次のタスク

複数の Windows サーバーをディスカバーしている場合は、以下のメッセージが表示されることがあります。

A Working gateway cannot be found

役立つ可能性のある追加構成について詳しくは、「TADDM トラブルシューティング・ガイド」の『ゲートウェイに関する問題』トピックを参照してください。

Cygwin SSH デーモンの構成Cygwin SSH デーモン (sshd) を使用して、Windows システムへの SSH アクセスが可能です。


ゲートウェイ・ベースのディスカバリーの場合、ゲートウェイ・システムにCygwin SSH デーモンをインストールする必要があります。ダイレクト SSH ディスカバリーの場合、各 Windows システムにこのデーモンをインストールする必要があります。

サポートされる Cygwin SSH デーモンのバージョンについて詳しくは、TADDMの「インストール・ガイド」の『Windows ゲートウェイ』トピックを参照してください。

重要: Cygwin SSH を使用してディスカバリーを正常に行うには、以下の要件が満たされている必要があります。

v Windows Server 2012 x64 および Windows Server 2008 x64 上の Cygwin 64ビット・エディションでアンカーとゲートウェイがサポートされている。

v ディスカバリー・ユーザーとサービスを開始するユーザーが同じでなければならない。ディスカバリー・ユーザーは、管理者グループのメンバーでなければなりません。

Cygwin は http://www.cygwin.com/ から入手できます。

手順

Cygwin SSH デーモンを構成するには、以下のようにします。

1. cygwin bash シェルを開始します。


http://www.cygwin.com/

2. cygwin mkpasswd ユーティリティーを使用して、システム情報から初期/etc/passwd を作成します。 mkgroup ユーティリティーを使用して、初期/etc/ グループを作成することもできます。詳しくは「Cygwin User's Guide」を参照してください。

例えば、次のコマンドを実行すると、システムのローカル・アカウントからパスワード・ファイル passwd がセットアップされます。

mkpasswd -l > /etc/passwd

3. ssh-host-config プログラム・セットアップを実行します。

4. SSH を構成します。すべての質問に対して Yes と応答します。

5. 次のコマンドを実行し、SSH サーバーを始動します。

net start sshd

次のタスク

Cygwin (sshd) サービスは、ゲートウェイ・サーバーへのアクセス時に管理ドメイン・ユーザー・アカウントを使用する必要があります。Microsoft Exchange センサーなどのいくつかのセンサーで、このユーザー・アカウントが必要です。以下のステップを実行します。

1. 次のコマンドを実行して、ドメイン・ユーザー・アカウントを構成します。

mkpasswd -u [domain_user] -d [domain] >> /etc/passwdmkgroup -d [domain] >> /etc/group

2. services.msc プログラムを開始してください。作成された Cygwin (sshd) サービス用のログオン・プロパティーを確認します。管理ドメイン・ユーザー・アカウントによって実行されるように、サービスがセットアップされていることを確認します。

3. Cygwin (sshd) 構成ファイルおよびログ・ファイルは、Cygwin (sshd) サービスがゲートウェイへのアクセスに使用するドメイン・ユーザー・アカウントと同じアカウントによって所有されている必要があります。以下のコマンドを実行します。

$ chown [domain_user] /var/log/sshd.log$ chown -R [domain_user] /var/empty$ chown [domain_user] /etc/ssh*

4. ドメイン・ユーザー・アカウントは、ゲートウェイ・サーバーで以下の操作を許可されている必要があります。

v プロセスのメモリー割り当て量の調整

v トークン・オブジェクトの作成

v サービスとしてのログオン

v プロセス・レベル・トークンの置き換え

複数の Windows サーバーをディスカバーしている場合は、以下のメッセージが表示されることがあります。

A Working gateway cannot be found

役立つ可能性のある追加構成について詳しくは、「TADDM トラブルシューティング・ガイド」の『ゲートウェイに関する問題』トピックを参照してください。

管理 143

Remotely Anywhere の構成Remotely Anywhere を使用して、Windows システムへの SSH アクセスが可能です。


サポートされる Remotely Anywhere のバージョンについて詳しくは、TADDM の「インストール・ガイド」の『Windows ゲートウェイ』トピックを参照してください。

ゲートウェイ・ベースのディスカバリーの場合、ゲートウェイ・システムにRemotely Anywhere をインストールする必要があります。

ダイレクト SSH ディスカバリーの場合、各 Windows システムに RemotelyAnywhere をインストールする必要があります。

Remotely Anywhere のデフォルトの構成値を使用することができます。詳しくは、http://remotelyanywhere.com/ を参照してください。

Tectia SSH Server の構成Tectia SSH Server を使用して Windows システムへの SSH アクセスが可能です。


サポートされる Tectia SSH Server のバージョンについて詳しくは、TADDM の「インストール・ガイド」の『Windows ゲートウェイ』トピックを参照してください。

ゲートウェイ・ベース・ディスカバリーを行う場合は、Tectia SSH Server をゲートウェイ・システムにインストールする必要があります。

ダイレクト SSH ディスカバリーを行う場合は、Tectia SSH Server を各 Windowsシステムにインストールする必要があります。

Tectia SSH Server のデフォルトの構成値を使用することが可能です。詳しくは、http://www.ssh.com を参照してください。

Windows Management Instrumentation (WMI) 依存関係TADDM は、Windows Management Instrumentation (WMI) に依存して、Windows コンピューター・システムをディスカバーします。WMI で問題が発生した場合に WMI サービスを再始動するように TADDM を構成できます。WMI サービスが再始動されると、再始動前に実行されていたすべての WMI 依存のサービスも再始動されます。

以下の TADDM サーバー・プロパティーにより、WMI の再始動が制御されます。

注: WMI 再始動のデフォルト値は false です。以下のプロパティーの値を trueに設定すると、Windows ディスカバリーの信頼性が高まる可能性がありますが、WMI サービスが一時的に停止して再始動するという悪影響が生じる可能性があることも考慮する必要があります。


http://remotelyanywhere.com/

http://www.ssh.com

v com.collation.RestartWmiOnAutoDeploy=false

v com.collation.RestartWmiOnAutoDeploy.1.2.3.4=false

v com.collation.RestartWmiOnFailure=false

v com.collation.RestartWmiOnFailure.1.2.3.4=false

Windows コンピューター・システム・センサーで使用される TADDM サーバーのプロパティーについて詳しくは、TADDM の「センサー解説書」の『collation.properties ファイルの構成』トピックを参照してください。

PowerShell セッション

Fix Pack 2

Windows コンピューター・システムをディスカバーするために、WMI セッションまたは PowerShell セッションを使用できます。PowerShell セッションを使用した場合、WMI セッションと比較すると、TADDM がターゲット・システムにアクセスするために送信する要求数が少ないため、記録されるイベント数が減少します。PowerShell セッションは、スクリプト・ベースのセンサーでのみ使用できます。PowerShell セッションを使用して開始したい場合、PowerShell セッションはデフォルトでは無効になっているため、有効にする必要があります。

両方のセッションを同時に使用することができます。通常のディスカバリーとスクリプト・ベースのディスカバリーを実行している場合、通常のディスカバリーはWMI セッションがないと失敗するため、WMI セッションを無効にすることはできません。ただし、PowerShell セッションの使用を優先することができます。

重要: 通常のディスカバリーのみ実行する場合は、PowerShell セッションはサポートされません。

以下のプロパティーを使用して、PowerShell セッションの使用と優先順位付けを制御できます。

v com.collation.PowerShellAccessEnabled=false

v com.collation.WmiAccessEnabled=true

v com.collation.PreferPowerShellOverWMI=true

v com.collation.PowerShellPorts=5985,5986

v com.ibm.cdb.session.ps.useSSL=false

v com.ibm.cdb.session.ps.allowDNS=true

v com.ibm.cdb.session.ps.fallbackToIP=true

v com.collation.PowerShellTimeoutFudge=10000

v Fix Pack 3 com.ibm.cdb.session.ps.urlPrefix=wsman

PowerShell セッションを有効にするには、com.collation.PowerShellAccessEnabled プロパティーを true に設定します。デフォルトでは、PowerShell セッションは WMI セッションより優先されます。

これらのプロパティーについて詳しくは、TADDM の「センサー解説書」でWindows コンピューター・システム・センサーについての『collation.properties

ファイルの項目の構成』を参照してください。

管理 145

注: 非常に特殊なケースでは、PowerShell セッションを使用した通信のみを許可するようにファイアウォールを構成した場合、PowerShell のポートを開き、ping センサーのプロパティーを構成することが必要になります。詳しくは、TADDM の「ユーザーズ・ガイド」の『アンカーのないファイアウォールを通過するディスカバリーの構成』トピックを参照してください。

シナリオの例

Windows ターゲット・システムをディスカバーする方法に応じて、前述のプロパティーを以下の方法で構成できます。

v スクリプト・ベースのディスカバリーをサポートするセンサーのみ使用しているとします。この場合、com.collation.PowerShellAccessEnabled プロパティーをtrue に設定して PowerShell セッションを有効にし、com.collation.WmiAccessEnabled プロパティーを false に設定して WMI セッションを無効にすることができます。ただし、PowerShell が使用不可の場合、セッションおよびディスカバリーは失敗します。

v スクリプト・ベースのディスカバリーと通常のディスカバリーをサポートするセンサーを使用しているとします。この場合、WMI セッションを無効にしないでください。WMI セッションを無効にすると、通常のディスカバリーは失敗するためです。com.collation.PowerShellAccessEnabled プロパティーを true に設定して、PowerShell セッションを有効にします。PowerShell セッションが可能な場合には必ず確立されるようにするために、com.collation.PreferPowerShellOverWMI プロパティーのデフォルト値を変更しないでください。この場合、TADDM は、PowerShell と WMI の両方の機能を使用できるハイブリッド・セッションを作成します。通常のセンサーで要求されたタスクを PowerShell セッションで実行できない場合にのみ、WMI セッションが使用されます。

プレースホルダーのディスカバリーの構成Fix Pack 3

インフラストラクチャー内で未検出の依存関係のプレースホルダーを作成するように TADDM を構成できます。

プレースホルダーとは、インフラストラクチャーの一部であるが、デフォルト設定では TADDM 内で表されないオブジェクトのことです。表されない理由として考えられるのは、接続の 1 つのサイドがディスカバーされないこと、そのタイプのオブジェクトをサポートするセンサーがないこと、またはそのオブジェクトに対して作成されたカスタム・サーバー・テンプレートがないことです。

プレースホルダーは、SSoftwareServer クラスに属しています。hierarchyDomain 属性と hierarchyType 属性が設定されています。以下の表に、属性の値を示します。

表 35. hierarchyDomain 属性値と hierarchyType 属性値

接続サイド hierachyDomain 属性値 hierarchyType 属性値

ローカル app.placeholder.client.local 接続の生成元のコマンドの名前 (例: Java)

リモート app.placeholder.server.remote Unknown


これらの値を使用して、ビジネス・アプリケーションのトラバーサル構成内の不要な関係をフィルタリングできます。詳しくは、TADDM の「ユーザーズ・ガイド」の『トラバーサル構成』トピックを参照してください。

プレースホルダーが作成され、同等のアプリケーション・サーバーがセンサーまたはカスタム・サーバー・テンプレートによって作成されると、PlaceholderCleanupAgent は、ディスカバーされたアプリケーション・サーバーとプレースホルダーをマージします。

注: TADDM 7.3.0.2 でもプレースホルダーを作成できますが、機能が制限されています。そのため、TADDM 7.3.0.3 以降でプレースホルダーを使用することをお勧めします。FP2 内で作成されたプレースホルダーの FP3 へのマイグレーションは、サポートされていません。

プレースホルダーの作成の有効化

プレースホルダーの作成を有効にするには、以下のプロパティーをcollation.properties ファイルに追加します。

com.ibm.cdb.topomgr.topobuilder.agents.ConnectionDependencyAgent2dependencyPlaceholders=true


このプロパティーを初めて true に設定するときには、TADDM を再始動して、LogicalConnection クラスおよび SoftwareServer クラスの拡張属性を有効にする必要があります。これらの拡張属性は、この機能が適切に動作するために必要です。

上記のプロパティーが true に設定されている場合は、collation.properties 内の以下のプロパティーを明示的に設定する必要はなく、代わりに、これらについてはコーディングされたデフォルト値が使用されます。

com.ibm.taddm.dependencyPlaceholders.create.localClient.to.remoteServer=true


com.ibm.taddm.dependencyPlaceholders.create.remoteClient.to.localServer=false


注: collation.properties でこれらのプロパティーを設定することにより、プレースホルダーの動作を変更できます。

重要: プレースホルダーの作成を有効にすると、ビジネス・アプリケーションが大幅に増大し、構築プロセスが長くなることがあります。そうならないように、ビジネス・アプリケーションのトラバーサル構成内の不要な関係をフィルタリングできます。

プレースホルダーの表示

フィルターを Placeholders に設定した後で、「インベントリーの要約」ペイン内にプレースホルダーを表示できます。未検出の依存関係のプレースホルダーは、「ソフトウェア・サーバー」タブにあります。

管理 147

カスタム・サーバー・テンプレートの作成

以下の方法で、プレースホルダーを使用して、カスタム・サーバー・テンプレートを作成できます。

v bizappscli ツールによって生成されたプレースホルダーについての情報を使用します。詳しくは、TADDM の「ユーザーズ・ガイド」の『ビジネス・アプリケーションのコンテンツを分析するためのアクション』トピックを参照してください。

v タイプ app.placeholder.*.local のプレースホルダーの「詳細」ペイン内の「ランタイム」タブに表示されるコマンド行情報を使用します。

カスタム・サーバー・テンプレートについて詳しくは、TADDM の「ユーザーズ・ガイド」の『カスタム・サーバー・テンプレートの作成および管理』トピックを参照してください。

資格情報なしのレベル 3 アプリケーション・サーバーの作成Fix Pack 2

インフラストラクチャー・エレメントに関する基本的なレベル 3 情報をディスカバーする場合、アクセス・リストの資格情報を提供する必要はありません。センサーの内部テンプレートを使用して、アプリケーション・サーバーを作成できます。このテンプレートは、CustomAppServerTopoAgent によって処理することも、またはカスタム・サーバー・テンプレート・センサーによるディスカバリーの実行中に処理することもできます。


資格情報を指定せずにアプリケーション・サーバーを作成すると、インフラストラクチャーについての基本情報 (例えば、インストールされているソフトウェアの種類) のみをディスカバーできます。レベル 3 ディスカバリーの資格情報を渡さずに、インフラストラクチャーに関する基本情報をディスカバーしたい場合に、このモードを選択してください。

レベル 3 アプリケーション・サーバーの作成方法は 2 とおりあります。カスタム・サーバー・テンプレート・センサーを実行することも、CustomAppServerTopoAgent を有効にすることもできます。

手順v カスタム・サーバー・テンプレート・センサーでディスカバリーを実行する

以下のステップを実行します。

1. collation.properties ファイルで、com.collation.internaltemplatesenabled プロパティーを true に設定します。このプロパティーにより、レベル 3 センサーの内部テンプレートが有効になります。デフォルト値は false です。

2. カスタム・サーバー・テンプレート・センサーを使用することにより、通常であれば目的の情報をディスカバーするセンサーが含まれていないプロファイルを使用して、ディスカバリーを実行します。例えば、DB2 サーバーの基本情報をディスカバーする場合は、レベル 2 のプロファイルのディスカバリー、または IBM DB2 センサーが含まれていない独自のプロファイルを選択


します。このプロファイルに IBM DB2 センサーが含まれている場合、カスタム・サーバー・テンプレート・センサーの代わりにこのセンサーが実行されます。

v CustomAppServerTopoAgent を実行するCustomAppServerTopoAgent は、汎用サーバー・センサーによって以前にディスカバーされたランタイム・プロセスを使用します。このエージェントは手動で実行することも、自動で実行されるように設定することもできます。以下のステップを実行します。

1. エージェントが手動モードの場合も自動モードの場合も、collation.properties ファイルのcom.collation.internaltemplatesenabled プロパティーを true に設定します。このプロパティーにより、レベル 3 センサーの内部テンプレートが有効になります。デフォルト値は false です。

2. 以下のコマンドを実行して、CustomAppServerTopoAgent を手動で開始します。

COLLATION_HOME/support/bin/runtopobuild.sh -a CustomAppServerTopoAgent

3. エージェントの自動実行をセットアップするために、collation.properties

ファイルの com.ibm.cdb.topobuilder.groupinterval.discovery= プロパティーを設定します。このプロパティーは、エージェントの実行頻度を指定します。デフォルトでは、値は指定されていません (つまり、エージェントは無効になっています)。有効にするには、値を時間単位で指定します (例えば、com.ibm.cdb.topobuilder.groupinterval.discovery=4)。

v オプション: 処理から除外するテンプレートを選択するレベル 3 センサーの内部テンプレートの一部のみを有効化する場合は、以下のプロパティーを使用して制御できます。

com.collation.discovery.ignoreTemplateList

このプロパティーは、処理から除外する内部テンプレートのリストを指定します。このプロパティーの値は、テンプレート名をセミコロンで区切ったリストです (例: com.collation.discovery.ignoreTemplateList=DB2Unix;MSSQL)。内部テンプレートの名前は、データ管理ポータルで、「その他のデータベース・サーバー」の「詳細」ペインの「一般」タブにある「オブジェクト名」フィールドで確認できます。

ロケーション・タグ付けの構成ロケーション・タグは、各構成アイテム (CI) が作成された場所を示します。これにより、BIRT レポートと API 照会で、構成アイテムをロケーションに基づいてフィルター処理できるようになります。

ロケーション・タグ付けを有効にすると、ディスカバリー・データベースに保管されている各ディスカバー済みオブジェクトに locationTag 属性 (ストリング) が組み込まれます。トポロジー・エージェントによって作成されたオブジェクト (関係オブジェクト、集約オブジェクト、継承オブジェクトなど) には、特定の条件下でロケーション・タグ・データが組み込まれます。

管理 149

v 両方の接続済みオブジェクトのロケーションが同じである場合、1 対 1 の関係(「依存関係」や「ネットワーク接続」など) にはロケーション・タグが組み込まれます。

v すべての集約オブジェクトのロケーションが同じである場合、クラスターなどの集約オブジェクトにはロケーション・タグが組み込まれます。

注: カスタム・コレクションの場合、locationTag 属性が設定されるのは、すべてのカスタム・コレクションのコア CI において、そのロケーション・タグのvalue が同じときに限られます。異なるロケーション・タグを持つコア CI を使用してカスタム・コレクションを拡張する場合、このようなカスタム・コレクションの locationTag 属性はクリアされます。

v 単純オブジェクトには、基礎となるオブジェクトのロケーション・タグが組み込まれます。

それ以外のすべての場合、トポロジー・エージェントによって作成されたオブジェクトにはロケーション・タグの値は組み込まれません。

ロケーション・タグ付けを有効にするには、collation.properties ファイルで次のプロパティーを設定してください。

com.ibm.cdb.locationTaggingEnabled=true

ロケーション・タグの値は、静的な値 (特定のサーバーやアンカー用に指定) にすることも、動的な値 (特定のディスカバリーや IdML ブック・インポート用に指定)にすることもできます。ロケーション・タグ値の長さは 192 文字までに制限されています。指定されたロケーション・タグが 192 文字を超える場合、必要な長さに切り捨てられます。

制限

レベル L1 ディスカバリーを実行する場合、データベースに既に存在している構成アイテムは更新されません。その結果、ロケーション・タグは新規にディスカバーされたオブジェクトのみに割り当てられます。

静的なロケーション・タグ付け静的なロケーション・タグ付けでは、TADDM またはアンカー・サーバーの静的構成に基づく IdML ブック・インポートを使用して、ディスカバーまたはロードされたすべてのオブジェクトに locationTag 属性が割り当てられます。

TADDM サーバー

TADDM サーバーで作成された CI のロケーション・タグの値を構成するには、collation.properties ファイルで次のプロパティーを指定します。

com.ibm.cdb.locationTag=location

location は、使用したいロケーション・タグの値です。

アンカー

アンカーで作成された CI のロケーション・タグの値を構成するには、$COLLATION_HOME/etc/anchor.properties ファイルで anchor_location_n 属性を構


成します。anchor.properties ファイル内の以下のサンプル項目は、アンカーのロケーション情報がどのように設定されるかを示しています。

anchor_host_1=192.168.1.13anchor_scope_1=FIRST_SCOPEanchor_zone_1=FIRST_ZONEanchor_location_1=FIRST_LOCATIONanchor_host_2=192.168.2.22anchor_scope_2=SECOND_SCOPEanchor_location_2=SECOND_LOCATIONPort=8497

アンカーのロケーション・タグが指定されていない場合、アンカーで作成された各CI のロケーションは、その CI の接続先 TADDM サーバー用に指定されたロケーションに設定されます。

アンカーにも TADDM サーバーにもロケーション・タグの値が指定されていない場合、その CI についてはロケーション情報は設定されません。

動的なロケーション・タグ付け動的なロケーション・タグ付けでは、特定のディスカバリーまたは IdML ブック・インポート用に指定された値を使用して、locationTag 属性が設定されます。

ディスカバリー

ディスカバリー中にロケーション・タグの値を指定するには、コマンド・ラインからディスカバリーを起動し、任意指定の -l オプションまたは -myLocation オプションを使用して、ロケーション・タグを指定します。以下に例を示します。api.sh -u administrator -p collation discover start -n discovery1 -p myProfile -l myLocation myScope

locationTag は、使用したいロケーション・タグの値です。指定した値により、この特定のディスカバリー中に作成されたオブジェクトに関するすべての静的ロケーション・タグの値がオーバーライドされます。

注: collation.properties ファイルでロケーション・タグ付けが有効になっていない場合、ディスカバリー要求時にロケーション・タグを指定すると、ディスカバリー例外が発生します。

IdML ブック・インポート

IdML ブックのインポート中にロケーション・タグの値を指定するには、任意指定の -l オプションを使用してロケーション・タグを指定します。以下に例を示します。

loadidml.sh -f idml_book.xml -l locationTag

locationTag は、使用したいロケーション・タグの値です。異なるロケーション・タグが指定された複数の IdML ブックをインポートする場合は、各ブックを別個にロードする必要があります。

アクセス・リストロケーション・タグが割り当てられたアクセス・リスト・エントリーを作成できます。

管理 151

ロケーション・タグ属性は必須ですが、後で変更することができます。資格情報はロケーションでフィルタリングされるため、特定のロケーションに関するアクセス・エントリーだけが使用されます。これにより、パスワードが他のユーザーやロケーションから盗聴される可能性が減少します。ロケーション・タグなしでディスカバリーを実行すると、タグ付きの資格情報は使用されません。

ロケーション・タグにアスタリスク文字 (*) が設定された新しいアクセス・エントリーを追加すると、このエントリーは、ディスカバリー時、エンドポイントへのセッション確立中に試行される最後のアクセス・エントリーとして使用されます。

アスタリスク文字 (*) はデフォルト値であり、以下のパラメーターを設定して変更できます。

com.ibm.cdb.locationTag.global=GLOBAL

このような場合、GLOBAL タグを持つアクセス・エントリーは、ディスカバリーの実行中に試行される最後のエントリーになります。上記のロケーション・タグは、アクセス・リストに対してのみ使用されます。ディスカバリー時にディスカバーされた CI に割り当てられるロケーション・タグには影響はありません。

BIRT レポートBusiness Intelligence and Reporting Tools (BIRT) レポートをフィルタリングして、特定の顧客ロケーションに関するデータを生成することができます。

ロケーション・タグ付けが有効になっている場合、BIRT レポート・ペインのレポート・リストの下にテキスト・フィールドが表示されます。任意のロケーション・タグに対して BIRT レポートを実行すると、そのロケーションに属するデータだけを表示することができます。

どのレポートも、そのままではロケーション・タグを処理することはできません。BIRT レポートを使用する必要がある場合は、ロケーション・タグによるフィルタリングをサポートするように手動で BIRT レポートを更新する必要があります。

保守とチューニングTADDM のパフォーマンスを最適化するために、追加の構成ステップと、継続的な保守作業を行うことをお勧めします。

バルク・ロード・パラメーターのチューニング実行時に特定のパラメーターを指定するか、bulkload.properties ファイルを構成することによって、バルク・ローダーの動作をカスタマイズできます。

バルク・ローダーを使用したデータのロードには、以下の 3 つの異なる段階があります。

1. オブジェクトおよび関係を分析して、データ内のグラフを判別する。

通常は実行時間の 1% から 5%

2. モデル・オブジェクトを構成して、グラフを作成する。



3. アプリケーション・プログラミング・インターフェース (API)・サーバーにデータを渡す。


データのロードには以下の 2 つのオプションがあります。

v データを一度に 1 レコードずつロードできます。これがデフォルトのモードです。以下のファイルについては、一度に 1 レコードずつロードする必要があります。

– エラーのあるファイル。

– 拡張属性を持つファイル。

v データをバルクでロードできます。これは、1 レコードのみでなくグラフ全体がロードされるため、グラフ書き込みと呼ばれます。

グラフ書き込みオプションを指定したバルク・ローディングでは、一度に 1 レコードずつロードするよりも速くローディングを実行できます。(詳しくは、バルク・ロードの測定値を参照してください)。以下にグラフ書き込みオプションの例を示します。-g=buffer およびデータ・ブロックが API サーバーに渡されます。

./loadidml.sh –g –f /home/confignia/testfiles/sample.xml

bulkload.properties 内の以下のパラメーターを使用することで、データのバルク・ローディング時のパフォーマンスを向上させることができます。

com.ibm.cdb.bulk.cachesize=2000

cachesize パラメーターは、グラフ書き込みオプションを指定したバルク・ローディング時に単一の書き込み操作で処理されるオブジェクトの数を制御します。このキャッシュ・サイズを大きくするとパフォーマンスは向上しますが、クライアントまたはサーバーのいずれかでメモリー不足になるリスクがあります。この数値は、より大きなキャッシュを使用してファイルを処理することに何らかのパフォーマンス上の利点があることを示す具体的な情報がある場合にのみ変更するようにしてください。デフォルトのキャッシュ・サイズ値は 2000、最大キャッシュ・サイズ値は 40000 です。

com.ibm.cdb.bulk.allocpoolsize=1024

この値により、バルク・ローダー・プロセスに割り振り可能な最大メモリー容量を指定します。これは、バルク・ローダーのメイン Java クラスに渡される Xmx値です。値はメガバイト単位で指定します。

Java 仮想マシンがメモリー不足になっていないことを確認してください。これは、TADDM プロセスのスレッド・ダンプを収集することによって確認できます。必要な場合は、メモリー・サイズを増やしてください。

ヒント: ITNMIP ブックで実行されたテストでは、バルク・ロード・プロセスのプロパティーおよびパラメーターを以下の値に設定するとパフォーマンスが最適化されることを示しています。

com.ibm.cdb.bulk.cachesize=4000com.ibm.cdb.bulk.allocpoolsize=4096value-Xms768M|-Xmx1512M|-DTaddm.xmx64=6g|

管理 153

http://www.ibm.com/support/docview.wss?uid=swg21598190

また、バルク・ロード・プロセス中に RUNSTATS コマンドを頻繁に実行することも重要です。

データベース保守システムのパフォーマンスを最良の状態に維持するには、TADDM データベースの定期的な保守およびチューニングを計画し、実行する必要があります。

デフォルトのデータベース構成

TADDM の PoC (概念検証)、テクノロジー検証、および小規模のパイロット実装が目的の場合には、TADDM に用意されているデフォルト・データベース構成で十分です。

DB2 データベースと Oracle データベースの両方のチューニングの指針

以下のチューニングの指針が DB2 データベースと Oracle データベースの両方に適用されます。

1. データベースが使用できる物理ディスク・ドライブの数を、記憶容量のみを基準にして制限しないようにしてください。

2. 理想的には、以下のコンポーネントを別々のディスク・ドライブまたはディスク・アレイに配置する必要があります。

v アプリケーション・データ (テーブルや索引など)

v データベース・ログ

v データベース一時スペース (ソート操作および結合演算に使用)

3. ログ・ファイル用には最も高速なディスクを使用してください。

4. オペレーティング・システム・レベルでの非同期入出力を有効にしてください。

DB2 データベースおよび Oracle データベースのチューニングについて詳しくは、http://www.redbooks.ibm.com/redbooks/pdfs/sg245511.pdf にある「DatabasePerformance Tuning on AIX」を参照してください。

DB2 データベースのチューニングに固有の情報について詳しくは、http://www-01.ibm.com/support/docview.wss?uid=tss1wp100764 にある「Relational Database Design and Performance Tuning for DB2 Database Servers」と、http://www.ibm.com/support/docview.wss?rs=71&uid=swg27009554 にある「DB2 UDB Version 8 Product Manuals」を参照してください。

古いデータベース・レコードの削除テーブル内のデータ・レコードの数は、時間の経過に応じて増加します。また、使用可能なストレージ・スペースの量によっては、テーブル内のデータをときどき手動で削除して、テーブルのサイズを減らすことをお勧めします。CHANGE_HISTORY_TABLE をクリアした後で、CHANGE_CAUSE_TABLE 内の対応する項目を削除することができます。また、ALIASES_JN テーブルから古いレコードを削除することにより、データ保全性ツールのパフォーマンスと使いやすさを向上させることができます。


http://www.redbooks.ibm.com/redbooks/pdfs/sg245511.pdf

http://www-01.ibm.com/support/docview.wss?uid=tss1wp100764

http://www.ibm.com/support/docview.wss?rs=71&uid=swg27009554

CHANGE_HISTORY_TABLE および CHANGE_CAUSE_TABLE からのレコードの削除:

古いレコードを削除することにより、パフォーマンスを向上させ、テーブルを小さなサイズに維持することができます。レコードを CHANGE_HISTORY_TABLE から削除した後で、対応する項目を CHANGE_CAUSE_TABLE から安全に削除することができます。

TADDM データベースのストレージ・スペースを解放するには、SQL 照会を使用して、CHANGE_HISTORY_TABLE から古いデータを手動で除去します。以下のコマンドはそのような SQL 照会の例で、整数 1225515600000 は 2008 年 11 月 1日という日付を、System.currentTimeMillis() Java メソッドが返す形式と同じ形式で表したもの (つまり、UTC 1970 年 1 月 1 日 0 時から現在時刻までの時間差をミリ秒単位で測定した数値) です。

DELETE FROM CHANGE_HISTORY_TABLEWHERE PERSIST_TIME < 1225515600000 (this is the Java time stamp)

日付を Java のタイム・スタンプに変換するには、以下のコードを使用してください。

import java.util.*;import java.text.*;import java.sql.Timestamp;

public class DateToString {

public static void main(String args[]) {try {

String str = args[0];SimpleDateFormat formatter = new SimpleDateFormat("dd/MM/yyyy");Date date = formatter.parse(str);

long msec = date.getTime();

System.out.println("Date is " +date);System.out.println("MillSeconds is " +msec);

} catch (ParseException e){System.out.println("Exception :"+e); }

}}

以下のようにしてコードを実行してください。

java DateToString 1/11/2008Date is Sat Nov 01 00:00:00 EST 2008MillSeconds is 1225515600000

結果として生成された Java のタイム・スタンプを SQL 照会で使用します。

CHANGE_HISTORY_TABLE に非常に多くのレコードが存在する場合は、データベースのトランザクション・ログがいっぱいにならないように、増分削除 (レコードのサブセットを一度に削除すること) の実行が必要になることがあります。

CHANGE_HISTORY_TABLE をクリアした後で、CHANGE_CAUSE_TABLE 内の対応する項目を安全に削除することができます。CHANGE_CAUSE_TABLE は、変更内容を伝搬するために使用されるリンク・テーブルです。例えば、オペレーティ

管理 155

ング・システムに新規のソフトウェア・コンポーネントを追加した場合、このテーブルは、そのオペレーティング・システムが稼働しているコンピューター・システムに変更内容をリンクします。 CHANGE_CAUSE_TABLE 内のレコードは、以下のコマンドを使用して削除できます。

delete from change_cause_table where cause_id not in (select id from change_history_table)

データを除去するための時間フレーム

時間の経過に応じたデータベースの増大を制限するために、TADDM で保管される変更履歴データのサイズを管理することができます。変更履歴テーブルからデータを除去するための最適な時間フレームを決定する際には、変更履歴データの用途、および他のアプリケーションが変更履歴情報を使用するかどうかを考慮してください。

変更履歴情報が別のアプリケーションによって使用されている場合は、CHANGE_HISTORY_TABLE に変更履歴データが保持される週の数より多くアプリケーションの同期を実行するようにしてください。

以下の例で、典型的なシナリオをいくつか説明します。

v 変更履歴データを問題判別のために使用していて、5 週間前に発生した問題を調査する場合には、CHANGE_HISTORY_TABLE のデータを 5 週間以上保持してください。

v Tivoli Business Service Manager (TBSM) の同期頻度が週に 1 回である場合は、変更履歴データを TADDM 変更履歴テーブルで保持する期間を 1 週間より長くしてください。

同期サーバー・デプロイメントでは、ドメイン・サーバーに大量の変更履歴データがあると、完全同期の所要時間が長くなることに注意してください。

同期サーバー・デプロイメントでのデータ保守

ドメイン・サーバー・デプロイメントでは、ドメインでのデータ・ニーズのみに基づいて、データ保守を決定できます。ただし、同期サーバー・デプロイメントでは、それぞれのドメイン・サーバー・データベースと同期サーバー・データベースの間で変更履歴データの除去を調整する必要があります。また、これらすべてのデータベースからデータを除去する必要があります。

同期サーバー・デプロイメントでは、データ保守に関する以下のガイドラインを使用してください。

v ドメイン・レベルの変更履歴データは、ドメイン・サーバー・データベースと同期サーバー・データベースの間の各スケジュール済み同期の間隔より長い期間にわたって保持してください。例えば、週に一度同期を行う場合は、各ドメイン・サーバー・データベースに 2 週間分以上の変更履歴データを保持します。

v まず、ドメイン・サーバー・データベースからデータを除去します。次に、同期サーバー・データベースからデータを除去します。

v 最良実施例は、すべての TADDM データベースで同じ週数の変更履歴データを維持することです。ただし、変更履歴データを同期サーバー・データベースに保持する期間は、こうしたデータがドメイン・サーバー・データベースに保持される期間とは異なる可能性があります。


v 自身の環境に固有の要件を満たすデータ除去の時間フレームを決定した後の最良実施例は、ドメイン・サーバー・データベースと同期サーバー・データベースの同期直後にデータ除去を行うことです。

ALIASES_JN テーブルからのレコードの削除:

ALIASES_JN テーブルから古いレコードを削除すると、データ保全性ツールのパフォーマンスと使いやすさが向上し、データベース内のスペースをさらに解放することができます。


ALIASES_JN テーブルには、ALIASES テーブルへの変更の履歴が含まれています。データ保全性ツールが、データベース内で構成アイテムのオーバー・マージと考えられるものを見つけるためには、収集されたデータを必要とします。時間が経つにつれて、ALIASES_JN テーブルのデータ・レコード数は増大し、かなりのサイズになります。このテーブルのサイズは、データ保全性ツールのパフォーマンスと使いやすさの両方に影響を及ぼし、TADDM データベースにおけるストレージ・スペースのニーズが増加します。

トポロジー・エージェント AliasesJnTableCleanup は、ALIASES_JN テーブルのクリーンアップを実行します。

デフォルトでは、30 日を超える古い行はすべて削除されます。collation.properties ファイルの以下のプロパティーを構成することにより、レコードの削除基準となる経過日数を変更することができます。

com.ibm.cdb.topomgr.topobuilder.agents.AliasesJnTableCleanupAgent.removeOlderThanDays=30

このプロパティーの値を -1 に設定すると、エージェントが使用不可になります。小さすぎる値を経過日数に指定すると、オーバー・マージ・オプションが指定されているデータ検証ツールで、不完全な結果が生成される場合があります。

デフォルトでは、エージェントの実行時間は 1800 秒 (30 分) 以下です。この時間が短くて、経過日数を過ぎた行の一部しか削除できなかった場合は、次回のエージェントの実行時に、残りの行の削除が試行されます。collation.properties ファイルの以下のプロパティーを構成することにより、エージェントのタイムアウト値を設定することができます。

com.ibm.cdb.topomgr.topobuilder.agents.AliasesJnTableCleanupAgent.timeout=1800

DB2 データベースの保守受け入れられるパフォーマンスを確保するには、TADDM DB2 データベースを定期的に保守する必要があります。


以下の DB2 ユーティリティーが使用可能です。

REORG可変長列の挿入、削除、および更新の各アクティビティーによって表データに数多くの変更が行われた後では、論理的に連続しているデータが、連続していない物理データ・ページ上にある場合があります。このため、データベ

管理 157

ース・マネージャーが、データにアクセスするために追加の読み取り操作を実行します。REORG ユーティリティーを使用して DB2 テーブルを再編成し、フラグメント化を解消して、スペースのレクラメーション処理を行います。RUNSTATS の実行にかかる時間が通常より長い場合や、DB2 のREORGCHK コマンドによって必要性が示された場合は、必要に応じて REORGユーティリティーを使用します。REORG ユーティリティーの実行時にはTADDM サーバーをシャットダウンしてください。オフラインでのテーブルや索引の再編成 (データのデフラグ) 中には、アプリケーションがテーブル内のデータにアクセスはできますが、更新はできないためです。ディスカバリーがなくても TopologyBuilder は頻繁に実行されるため、このようなロックは、アプリケーション内で予測不能な結果を発生される可能性があります。

RUNSTATS (手動統計コレクション)DB2 最適化プログラムは、指定された照会に基づいて DB2 カタログ内の情報および統計を使用して、データベースへの最適なアクセスを判別します。RUNSTATS ユーティリティーを実行すると、ローカル・データベース内の特定の表および索引に関する統計情報が収集されます。かなり多くのテーブル行が追加または除去されたときや、統計の収集対象となる列のデータが更新された場合は、RUNSTATS コマンドを使用して統計を更新する必要があります。最適なパフォーマンスを得るためには、RUNSTATS タスクを週次または日次 (データベース・アクティビティーが活発な状態の場合) で実行します。統計が更新されていないと、TADDM のパフォーマンスが大きく低下する可能性があります。RUNSTATS ユーティリティーは、TADDM サーバーの実行中に実行できます。TADDM は、後で説明するように特定のRUNSTATS 形式を必要とします。また、DB2 の AUTO_RUNSTATS オプションをオフにする必要があります。

AUTO_RUNSTATS (自動統計コレクション)自動統計コレクション (auto-runstats とも呼ばれます) を有効にして、TADDM データベース統計を更新する必要があるかどうかを DB2 に判断させることができます。RUNSTATS ユーティリティーがバックグラウンドで実行され、データベース統計が常に更新されます。

自動統計コレクションを有効にするには、パラメーター AUTO_MAINT、AUTO_TBL_MAINT、および AUTO_RUNSTATS を ON に設定する必要があります。以下のコマンドを実行します。

CONNECT TO <db alias>UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_RUNSTATS ON

ここで、<db alias> はデータベースの名前です。

制約事項: このユーティリティーは、DB2 APAR IT05733 がインストールされ、DB2_SELECTIVITY=DSCC パラメーターが設定されている場合にのみ使用することができます。DB2 APAR IT05733 は、以下のリリースおよびそれ以降のリリースの DB2 に含まれています。

v 9.7 フィックスパック 11




DB2 バージョン 10.x で DB2_SELECTIVITY=DSCC パラメーターを設定するには、以下のコマンドを実行します。

db2set -immediate DB2_SELECTIVITY=DSCC

注: DB2 9.7 では -immediate パラメーターはサポートされません。このバージョンで DB2_SELECTIVITY=DSCC パラメーターを設定するには、db2setDB2_SELECTIVITY=DSCC コマンドを実行し、DB2 を再始動します。

注: TADDM ユーザーが TADDM インストール済み環境で DB2 バージョンをアップグレードした場合は、ドライバーの互換バージョンも更新する必要があります。TADDM DB2 サーバーの db2jcc.jar を DBA に要求することも、使用する DB2 のバージョンに適したドライバーをhttp://www-01.ibm.com/support/docview.wss?uid=swg21363866 からダウンロードすることもできます。入手したら、TADDM を停止し、ドライバーを dist/lib/jdbc/ にコピーし、TADDM ユーザーがファイルを読み取ることができるように許可が正しいことを確認してから、TADDM を始動します。環境内のすべての TADDM サーバーで、この手順を繰り返します。

DB2 ヘルス・モニターRUNSTATS、REORG などの調整が必要な状態に変化した場合、プロアクティブにモニターするために TADDM データベースに対して DB2 ヘルス・モニターを実行することをお勧めします。ヘルス・モニターは、システムの正常性に関する潜在的な問題をデータベース管理者に警告できます。ヘルス・モニターは、ハードウェア障害を引き起こしたり、システム・パフォーマンスまたは機能を許容できないほど低下させたりする可能性がある問題をプロアクティブに検出します。プロアクティブなヘルス・モニターによって、システム・パフォーマンスに影響が及ぶ問題になる前に、問題に対応できます。

DB2 PERFORMANCE ANALYSIS SUITEDB2 の問題が疑われる場合、Performance Analyst ツールによって、問題の時点で取得された DB2 スナップショットを迅速に分析し、アクションを推奨できます。このツールは、https://www.ibm.com/developerworks/community/groups/community/perfanalyst でダウンロードできます。

TADDM の DB2 スナップショットを取得するには、次の手順を実行します。

1. DB2 サーバーから TADDM データベースに接続し、次のコマンドを実行します。

db2 -tf updmon.sql

ここで、updmon.sql ファイルには次の項目が含まれています。

UPDATE MONITOR SWITCHES USING BUFFERPOOL ON ;UPDATE MONITOR SWITCHES USING LOCK ON ;UPDATE MONITOR SWITCHES USING SORT ON ;UPDATE MONITOR SWITCHES USING STATEMENT ON ;UPDATE MONITOR SWITCHES USING TABLE ON ;UPDATE MONITOR SWITCHES USING UOW ON ;UPDATE MONITOR SWITCHES USING TIMESTAMP ON ;RESET MONITOR ALL

管理 159

http://www-01.ibm.com/support/docview.wss?uid=swg21363866

https://www.ibm.com/developerworks/community/groups/community/perfanalyst

https://www.ibm.com/developerworks/community/groups/community/perfanalyst

2. ステップ 1 が完了したら、『DB2 get monitor switches』コマンドを実行して、モニターのスイッチがすべて設定されているかどうかを確認します。状況はすべて ON になっている必要があります。

3. パフォーマンスの問題があるプロセスを実行します。

4. 遅いプロセスの実行中に、適切な間隔で次のコマンドを DB2 から実行します。

db2 get snapshot for all on <dbname> > <dbname>-dbsnap.out

このコマンドを、ステップ 1 でコマンドを実行したのと同じウィンドウから実行します。このコマンドは、スクリプトを使用して実行することはできません。

5. 毎回異なるタイムスタンプの出力ファイルを使用して、スナップショットを複数回取得します。プロセス中に 3 から 4 回スナップショットを取得する間隔で実行しますが、実行間の時間が 1 時間を超えないようにします。

スナップショットが収集されたら、Performance Analyst ツールを使用して最後のスナップショットから順にスナップショットを分析します。例えば、何度も実行される照会の「ステートメント」タブで CPU 使用率および平均実行時間が高いのは、通常、最適化の問題を示しています。これは、RUNSTATS ユーティリティーで解決できます。「表」タブのオーバーフロー・パーセントが高いのは、REORG ユーティリティーが必要であることを示している可能性があります。「バッファー・プール」タブを調べて、アラートがないことを確認してください。バッファー・プールが小さすぎるとパフォーマンスが低下する場合があります。

始める前に

スキーマの変更が生じる大規模な保守の後、例えばフィックスパックの適用後などは、TADDM ストレージ・サーバーで TADDM_table_statistics.sqlファイルを生成する必要があります。このファイルは、定期的に実行する必要がある RUNSTATS データベース保守タスクに必要です。TADDM は、データベース統計の更新に特殊な形式を必要とします。TADDM では広範囲にわたって使用される、クラス名などの大容量の共通プレフィックスがある列を処理するときの DB2 の制限のためです。このため、DB2 のAUTO_RUNSTATS オプションを使用せずに、次の手順を実行することで生成される RUNSTATS 構文を使用してください。ただし、DB2 APAR IT05733 がインストールされ、DB2_SELECTIVITY=DSCC パラメーターが設定されている場合は、AUTO_RUNSTATS オプションを使用できます。

注: 以下の説明は Linux および UNIX オペレーティング・システムに適用されます。Windows オペレーティング・システムでデータベース保守を実行するには、.sh スクリプトの代わりに、対応する .bat スクリプトを使用します。

TADDM_table_stats.sql ファイルを生成するには、次の手順を実行します。

1. 以下のコマンドを実行します。

cd $COLLATION_HOME/bin

2. 次のコマンドを実行します。ここで、tmpdir は、このファイルを作成可能なディレクトリーです。


./gen_db_stats.jy > tmpdir/TADDM_table_stats.sql

ストリーミング・サーバー・デプロイメントでは、このコマンドを 1次ストレージ・サーバーで実行します。

3. 手順のステップ 2 に示すように TADDM データベースに対してこのファイルを実行するために、データベース・サーバーにファイルをコピーするか、データベース管理者 (DBA) に提供します。テーブルに大規模な変更がある場合は、データベース統計を週次、またはより頻繁に更新してください。

手順

DB2 データベースに対する保守を実行するには、以下のステップを実行します。

1. REORG ユーティリティーを使用するには、以下のステップを実行します。

a. データベース・サーバー上のファイルに、次の SQL 照会を配置します。この SQL 照会は REORG TABLE コマンドを生成します。

select 'reorg table '||CAST(RTRIM(creator) AS VARCHAR(40))||'."'||substr(name,1,60)||'" ; ' from sysibm.systables where creator= 'dbuser' and type = 'T' and name not in ('CHANGE_SEQ_ID')order by 1;

ここで、dbuser は、com.collation.db.user= からの値です。

注: dbuser の文字の大/小文字が、データベースの sysibm.systables 表の列 creator に指定された値と同じであることを確認してください。

b. TADDM サーバーを停止します。

c. DB2 コマンド・ラインでデータベースに接続し、以下のコマンドを実行します。

db2 –x –tf temp.sql > cmdbreorg.sqldb2 –tvf cmdbreorg.sql > cmdbreorg.out

d. cmdbreorg.out ファイルでエラーがないかどうかを調べて、REORG ユーティリティーが正常に実行されたことを確認してください。

e. TADDM サーバーを開始してください。

2. RUNSTATS ユーティリティーを使用するには、次の手順を実行します。このプロセスを少なくとも週次で自動的に実行するようにします。

a. データベース・サーバーで、前に生成した出力を使用することで TADDM固有の RUNSTATS コマンドを実行します。

db2 -tvf tmpdir/TADDM_table_stats.sql > table_stats.out

b. table_stats.out ファイルでエラーがないかどうかを調べて、RUNSTATS ユーティリティーが正常に実行されたことを確認してください。

DB2 for z/OS データベースの保守以下の保守およびチューニングの指針は、IBM DB2 for z/OS® データベースに適用されます。

管理 161

手順

以下のガイドラインでは、DB_USER は 1 次 DB2 データベース・ユーザー ID であり、ARCHIVE_USER は 2 次 DB2 データベース・ユーザー ID であることが前提となっています。

1. ディスカバリー管理コンソールを使用してディスカバリーを実行します。このメソッドによって、ドメイン・データベースにデータが取り込まれます。


3. TADDM で使用される各テーブル・スペースの REORG 制御ステートメントを生成して実行します。

SELECT 'REORG TABLESPACE '||DBNAME||'.'||NAME FROM SYSIBM.SYSTABLESPACEWHERE CREATOR IN ('DB_USER', 'ARCHIVE_USER') ORDER BY 1;

4. TADDM で使用される索引の REORG 制御ステートメントを生成して実行します。

SELECT 'REORG INDEX '||CREATOR||'.'||NAME FROM SYSIBM.SYSINDEXESWHERE CREATOR IN ('DB_USER', 'ARCHIVE_USER');

5. TADDM で使用されるテーブル・スペースの RUNSTATS 制御ステートメントを生成して実行します。

SELECT 'RUNSTATS TABLESPACE '||DBNAME||'.'||NAME||' INDEX(ALL)SHRLEVEL REFERENCE' FROM SYSIBM.SYSTABLESPACEWHERE CREATOR IN ('DB_USER', 'ARCHIVE_USER') ORDER BY 1;

6. 各 TADDM DB ユーザーの UPDATE 索引統計ステートメントを再生成して実行します。

SELECT 'UPDATE SYSIBM.SYSINDEXES SET FIRSTKEYCARDF=FULLKEYCARDFWHERE NAME = '||''''||CAST(RTRIM(name) AS VARCHAR(40))||''''||'AND CREATOR = '||''''||CAST(RTRIM(creator) AS VARCHAR(40))||''''||'AND TBNAME = '||''''||CAST(RTRIM(tbname) AS VARCHAR(40))||''''||'AND TBCREATOR = '||''''||CAST(RTRIM(tbcreator) AS VARCHAR(40))||''''||';'from sysibm.sysindexes awhere tbcreator in ('DB_USER', 'ARCHIVE_USER')AND NAME IN(SELECT IXNAMEFROM SYSIBM.SYSKEYS BWHERE A.CREATOR = B.IXCREATORAND A.NAME = B.IXNAMEAND COLNAME = 'PK__JDOIDX')AND TBNAME IN(SELECT NAMEFROM SYSIBM.SYSTABLES CWHERE A.TBCREATOR = C.CREATORAND A.TBNAME = C.NAMEAND CARDF > 0);

ここで、DB_USER は 1 次 DB2 データベース・ユーザー ID であり、ARCHIVE_USER は 2 次 DB2 データベース・ユーザー ID です。

7. 各 TADDM DB ユーザーの UPDATE 列統計ステートメントを再生成して実行します。

SELECT 'UPDATE SYSIBM.SYSCOLUMNS SET COLCARDF=(SELECT FULLKEYCARDF FROMSYSIBM.SYSINDEXES WHERE NAME = '||''''||CAST(RTRIM(name)AS VARCHAR(40))||''''||'AND CREATOR = '||''''||CAST(RTRIM(creator) AS VARCHAR(40))||''''||'AND TBNAME = '||''''||CAST(RTRIM(tbname) AS VARCHAR(40))||''''||'AND TBCREATOR = '||''''||CAST(RTRIM(tbcreator) AS VARCHAR(40))||''''||')WHERE NAME = '||''''||'PK__JDOIDX'||''''||' AND TBNAME = '||''''||CAST(RTRIM(tbname) AS VARCHAR(40))||''''||'


AND TBCREATOR = '||''''||CAST(RTRIM(tbcreator) AS VARCHAR(40))||''''||';'from sysibm.sysindexes awhere tbcreator in ('DB_USER', 'ARCHIVE_USER')AND NAME IN(SELECT IXNAMEFROM SYSIBM.SYSKEYS BWHERE A.CREATOR = B.IXCREATORAND A.NAME = B.IXNAMEAND COLNAME = 'PK__JDOIDX')AND TBNAME IN(SELECT NAMEFROM SYSIBM.SYSTABLES CWHERE A.TBCREATOR = C.CREATORAND A.TBNAME = C.NAMEAND CARDF > 0);

8. TADDM の使用状態に基づいて最大のテーブルを定期的にモニターし、必要に応じてストレージ属性を調整してください。特に、大きくなる可能性がある、以下のデータベース表のサイズをモニターしてください。v ALIASESv CHANGE_CAUSE_TABLEv CHANGE_HISTORY_TABLEv MSSOBJLINK_RELv PERSOBJv SUPERIORS

ALTER ステートメントを使用して、ご使用の環境の要件に従って PRIQTY および SECQTY の属性を変更します。該当する場合は、別のテーブル・スペースへのテーブルの移動を検討してください。

9. 以下のパッケージで、REBIND コマンドに KEEPDYNAMIC(YES) オプションを指定して使用します。v SYSLH200v SYSLH201v SYSLH202

Oracle データベースの保守以下の保守およびチューニングの指針は、Oracle データベースに適用されます。

1. データベース表で dbms_stats パッケージを実行します。 Oracle では、コスト・ベースの最適化プログラムを使用します。コスト・ベースの最適化プログラムではアクセス・プランを決定するためのデータが必要となり、このデータを生成するのが dbms_stats パッケージです。 Oracle データベースには、表および索引に関するデータが不可欠です。このデータがない場合、最適化プログラムは評価を実行する必要があります。

索引の再作成および dbms_stats パッケージの実行は、Oracle データベースで最良のパフォーマンスを得る上で非常に重要です。データベースにデータを追加した後は、スケジュールに基づいて定期的に (例えば週に 1 度) この作業を実行する必要があります。

v REBUILD INDEX: 挿入、削除、および更新アクティビティーによって表データに数多くの変更が行われた後では、論理的に連続しているデータが非連続的な物理データ・ページ上にあるために、データベース・マネージャーが、デ

管理 163

ータにアクセスするために追加の読み取り操作を実行しなければならないことがあります。索引の再作成は、SQL のパフォーマンスを向上させる上で役に立ちます。

a. Oracle データベースで以下の SQL ステートメントを実行して REBUILDINDEX コマンドを生成します。ここで、dbuser はcom.collation.db.user= の値です。

select 'alter index dbuser.'||index_name||' rebuild tablespace '||tablespace_name||';' from dba_indexes where owner = 'dbuser'and index_type not in ('LOB');

これにより、実行する必要のあるすべての ALTER INDEX コマンドが生成されます。

b. SQLPLUS またはそれに類する機能を使用して、これらのコマンドを実行します。索引の再作成は、大容量のデータベースの場合で 15 分から20 分かかります。

2. DBMS_STATS: Oracle RDBMS を使用して、パフォーマンスの向上に役立てるためのさまざまな種類の統計を収集します。最適化プログラムは、用意された照会に基づいてディクショナリー内の情報および統計を使用し、データベースへの最適なアクセスを判別します。 DBMS_STATS コマンドを実行すると、ローカル・データベース内の特定の表および索引に関する統計情報が収集されます。非常に多くのテーブル行が追加または除去されたか、統計の収集対象となる列のデータが更新された場合は、再度 DBMS_STATS コマンドを実行して統計を更新してください。

v $COLLATION_HOME/bin ディレクトリー内の gen_db_stats.jy プログラムは、TADDM 表に関する統計を更新するための Oracle データベースまたは DB2データベース用のデータベース・コマンドを出力します。このプログラムの使用方法の例を以下に示します。

a. cd $COLLATION_HOME/bin

b. この SQL ステートメントを実行します。ここで、tmpdir は、このファイルが作成されるディレクトリーです。

./gen_db_stats.jy > tmpdir/TADDM_table_stats.sql

ストリーミング・サーバー・デプロイメントでは、このステートメントを 1 次ストレージ・サーバーで実行します。

c. 完了後、このファイルをデータベース・サーバーにコピーして、以下のコマンドを実行します。

– SQLPlus でスクリプト・ファイルを実行するには、SQL > @{file} のように、@ に続けてファイル名を入力します。

d. SQLPLUS またはそれに類する機能を使用して、これらのコマンドを実行します。

3. バッファー・プール: バッファー・プールまたはバッファー・キャッシュは、各インスタンスの Oracle システム・グローバル域 (SGA) 内にあるメモリー構造です。このバッファー・キャッシュは、メモリー内にデータ・ブロックをキャッシングするために使用されます。メモリー内のデータへのアクセスは、ディスク内のデータへのアクセスよりもかなり高速です。ブロック・バッファーをチューニングする目的は、頻繁に使用されるデータ・ブロックをバッファー・キャッシュ (SGA) に効率よく入れ、データへのより高速なアクセスを実現することで


す。ブロック・バッファーのチューニングは、Oracle のチューニングを開始するに当たっての主要な作業であり、実動データベースのその後のチューニングおよびモニター作業でも実行する作業です。 Oracle 製品では、各インスタンスのSGA 内でその独自のバッファー・キャッシュが保守されます。適正サイズに設定されたバッファー・キャッシュであれば、通常、90% を超えるキャッシュ・ヒット率を達成できます。これは、10 個の要求のうちの 9 個は、ディスクにアクセスしなくても満たすことができるということです。バッファー・キャッシュが小さすぎると、キャッシュ・ヒット率が下がり、より多くの物理ディスク入出力が実行されることになります。バッファー・キャッシュが大きすぎると、バッファー・キャッシュの一部を利用しきれずに、メモリー・リソースを浪費することになります。

表 36. バッファー・プール・サイズの指針 (db_cache_size)

CI の数指針となるバッファー・プール・サイズ

< 500,000 38000

500,000 - 1,000,000 60000

> 1,000,000 95000

4. ディスカバリーまたはバルク・ロードの完了までに時間がかかりすぎて NRS に以下のエラーが含まれる場合には、最大オープン・カーソルのサイズを倍にすることができます。

com.ibm.tivoli.namereconciliation.service.NrsServicegetAliases(masterGuid)SEVERE: NOTE ^*** SQL State = 60000. SQL Code = 604. SQL Message =ORA-00604: error occurred at recursive SQL level 1ORA-01000: maximum open cursors exceededORA-01000: maximum open cursors exceeded

5. ご使用の Oracle JDBC ドライバーと Oracle サーバーのバージョンが同じことを確認してください。必要な場合は、以下の場所にある Oracle JDBC ドライバー・ファイルを置き換えます。

注: これが該当するのは、BIRT レポート・ビューアーが有効の場合のみです。

v TADDM 7.3.0 - $COLLATION_HOME/deploy-tomcat/birt-viewer/WEB-INF/

platform/plugins/

org.eclipse.birt.report.data.oda.jdbc_2.2.1.r22x_v20070919/drivers/

v TADDM 7.3.0.1 以降 - $COLLATION_HOME/apps/birt-viewer/WEB-INF/

platform/plugins/

org.eclipse.birt.report.data.oda.jdbc_2.2.1.r22x_v20070919/drivers/

v $COLLATION_HOME/lib/jdbc/

データベース通信データベースが使用不可になると、ストレージ・サーバーは、接続の再確立を試みます。

データベースとストレージ・サーバー間の接続が失われると、ストレージ・サーバーは、com.ibm.cdb.db.timeout プロパティーに指定された時間だけ待機した後、データベースへの接続を試みます。接続の確立を再試行する回数は、com.ibm.cdb.db.max.retries プロパティーに指定されています。

管理 165

データベース・プロパティーについて詳しくは、『データベース・プロパティー』セクションを参照してください。

ディスカバリー・パフォーマンスのチューニングcollation.properties ファイルにある com.collation.discover.dwcount プロパティー、com.collation.discover.observer.topopumpcount プロパティー、およびcom.ibm.cdb.discover.observer.topopump.threshold プロパティーを更新して、ディスカバリー速度、およびディスカバリー結果が TADDM データベースに保管されるときの速度を調整するか、またはデータの保管に使用されるスレッド数を制限することができます。

これらのプロパティーについて詳しくは、 102 ページの『パフォーマンス・プロパティー』を参照してください。

com.collation.discover.dwcount またはcom.collation.discover.observer.topopumpcount プロパティーの値を増加する場合は、以下の Java 仮想マシン (JVM) の最大ヒープ・サイズの設定値を増やすことにより、インストール済みメモリーの容量も増加しなければならないことがあります。

dwcount プロパティーの場合:

v ストリーミング・サーバー・デプロイメントの場合:

– Discover

– DiscoverService

v ドメイン・サーバー・デプロイメントの場合:

– Discover

topopumpcount プロパティーの場合:

v ストリーミング・サーバー・デプロイメントの場合:

– StorageService

v ドメイン・サーバー・デプロイメントの場合:

– Topology

詳しくは、 169 ページの『Java 仮想マシン: IBM パラメーターのチューニング』を参照してください。

ディスカバリー・パラメーターのチューニングについて詳しくは、http://www.ibm.com/software/brandcatalog/ismlibrary/ にある「TuningDiscovery Performance」というタイトルの資料を参照してください。

ディスカバリー速度のチューニングディスカバリー速度属性は、チューニングとの関係が最も深い領域です。パフォーマンスに最も影響するプロパティーは、ディスカバー・ワーカー・スレッドの数です。進行中センサーを使用してパフォーマンスをモニターしたり、セッション・プール・サイズを指定することによってパフォーマンスを向上させたりすることもできます。


http://www.ibm.com/software/brandcatalog/ismlibrary/

ディスカバー・ワーカー・スレッドは、センサーを実行するスレッドです。次のプロパティーは、ディスカバー・ワーカー・スレッドの最大数を指定します。

com.collation.discover.dwcount=32

サーバーに予備の容量が十分にある場合は、この数を増やし、より多くのセンサーを並列実行させることができます。

進行中センサー

パフォーマンスをモニターするために、進行中センサーを見ることができます。進行中センサーには、以下の 3 つの実行ステージがあります。

開始済みこのステージのセンサーは、CI をディスカバーしています。

ディスカバー済みこのステージのセンサーは、CI のディスカバーを終了していますが、その結果がデータ・ストアに保存されるのを待機しています。

保管中このステージのセンサーは、ディスカバリー結果をデータベースに保存します。

実行ステージ別に進行中センサーの順序付けを行うには、「説明」列をクリックします。

ディスカバリーの実行を監視し、開始済みステージにある進行中センサーの数とディスカバー済みステージまたは保管中ステージの進行中センサーの数を比較することにより、特定の環境において属性のディスカバリーが属性のストレージよりも速いか遅いかを評価することができます。collation.properties ファイルに対するすべての変更の場合と同様に、変更を有効にするには、サーバーを再始動する必要があります。

例:

進行中センサー: 開始済み、ディスカバー済み、保管中。

(ディスカバー済み + 保管中) の数が開始済みの数より小さい場合は、ディスカバリーがパフォーマンス・ボトルネックになっていることを示す可能性があります。

(ディスカバー済み + 保管中) の数が開始済みを超過する場合は、ストレージがパフォーマンス・ボトルネックになっていることを示す可能性があります。

セッションおよびゲートウェイのプール・サイズ

特定の CI の属性をディスカバーするため、センサーでは、そのホスト・コンピューターとの SSH または WMI セッションが必要です。パフォーマンスを向上させるため、これらのセッションはプールされてキャッシュされます。デフォルトのプール・サイズはほとんどの場合に十分な大きさですが、十分なサイズではない場合は、ディスカバリー速度が制限される可能性があります。この状態をモニターするために、次のプロパティーを true に変更することができます。

com.collation.platform.session.ExtraDebugging=false

管理 167

変更を有効にするには、ディスカバリー・サーバーを再始動する必要があります。ディスカバリーの実行後は、DiscoverManager ログで、セッション・プールに関連した待機時間の問題を検索できます。そのためには、ログで pool lock を検索します。セッション・プールの競合によって発生するパフォーマンス低下の例を以下に示します。

2006-08-04 16:11:50,733 DiscoverManager [DiscoverWorker-34]WindowsComputerSystemAgent(192.168.16.181)INFO session.SessionClientPool -Session client [3x ssh2:/[email protected]]#9612508waited 158.682 seconds for pool lock

セッションの待機時間が長すぎる場合は、プール・サイズを増加することができます。これには 2 つの方法があります。ホストあたりのセッション用のプール・サイズは、collation.properties ファイルにある以下のプロパティーを編集することによってグローバルに変更できます。

com.collation.platform.session.PoolSize=3

ただし、競合が、環境内のすべてまたはほとんどのホストのセッションに関係するというようなことは考えられません。競合は通常、多くのセンサーによって使用される、大量のホストの中の小数のホストに限定されます。ディスカバリー・サーバーはスコープ付きプロパティーを使用しますが、これは、collation.properties ファイル内の多くのプロパティーが、一般のターゲットに対してある値を使用し、特定のターゲットに対しては別の値を使用することを意味します。このプロパティーは、以下の例に示すように、IP アドレスまたはディスカバリー・サーバー・スコープ名を追加することによって調整できます。

com.collation.platform.session.PoolSize.10.10.250.1=20

この場合、10.10.250.1 用のプールサイズは 20 ですが、その他すべてのホストの場合には 3 です。DiscoverManager ログにあるようなログ・メッセージを見て、デフォルトのセッション・プール・サイズでは不十分なホストを判別し、それに応じて collation.properties ファイルに変更を加えることができます。

関連する設定は、ゲートウェイ・プール・サイズです。これにより、ディスカバリー・サーバーと Windows ゲートウェイの間で許可されるセッション数が設定されます。この値は、次のプロパティーを編集することによって指定できます。

com.collation.platform.session.GatewayPoolSize=10

ご使用の環境が主に Windows コンピューター・システムで構成されている場合は、このプロパティーを上方に調整し、ディスカバー・ワーク・スレッドの数と等しくなるようにしてください。

ストレージのチューニングストレージは、チューニングすることができる 2 番目に重要な領域です。保管中ステージにあるセンサーの数が並列ストレージ・スレッドの数を指定するプロパティーの値とほぼ同じになると、ディスカバリー結果のストレージが原因でパフォーマンスのボトルネックが起こるようになります。パフォーマンスを改善するために、データの保管を担当するスレッドの数を制限することもできます。

次のプロパティーは、並列ストレージ・スレッドの数を指定します。これは、ディスカバリーのストレージ・パフォーマンスを制御する主要な設定の 1 つです。


com.collation.discover.observer.topopumpcount

トポロジー・エージェントの稼働時のストレージのパフォーマンスを改善するために、ディスカバリー中のデータの保管を担当するスレッドの数を制限することができます。この結果、ディスカバリーの完了に要する時間が少なくなります。実行するスレッド数の制限を指定するには、collation.properties ファイル内の以下のプロパティーを編集します。

com.ibm.cdb.discover.observer.topopump.thresholdこのプロパティーは、制限するストレージ・スレッドの数を指定します。

com.ibm.cdb.discover.observer.topopump.threshold.<agentGroupName>このプロパティーは、指定のエージェント・グループの稼働時に制限するストレージ・スレッドの数を指定します。

以下の表は、com.ibm.cdb.discover.observer.topopump.threshold プロパティーによってディスカバリーのパフォーマンスをどの程度向上できるかを示しています。この計算では、76000 の構成アイテムを持つデータベースを使用しています。

しきい値プロパティーの値時間の向上の割合

0.2 55

0.5 33

0.7 13

1 0

Java 仮想マシン: IBM パラメーターのチューニングJava ヒープのフラグメント化を軽減し、パフォーマンス向上に役立つ Java 仮想マシン (JVM) のパラメーターを設定できます。

処理されるオブジェクトの数が増えるにつれて、Java ヒープのフラグメント化が発生する可能性があります。ヒープのフラグメント化を軽減するのに役立つ設定可能ないくつかのパラメーターがあります。

v kCluster は、クラス・ブロック専用に使用されるストレージ域です。これには1280 項目入るだけの大きさがあります。各クラス・ブロックの長さは 256 バイトです。多くの場合、このデフォルト値では小さすぎるため、ヒープのフラグメント化が発生します。以下のようにして kCluster パラメーター -Xk を設定すると、ヒープのフラグメント化の軽減に役立ちます。これらは初期値であり、環境に合わせて調整する必要がある場合があります。適正サイズを判別する方法としては、ヒープ・ダンプの分析が最適です。

– Topology: -Xk8300

– EventsCore: -Xk3500

– DiscoverAdmin: -Xk3200

– Proxy: -Xk5700

– Discover: -Xk3700

管理 169

「JVM Vendor Specific Settings」セクションに項目を追加することで、collation.properties ファイルにこれらの変更を実装してください。例えば、トポロジー・サーバーに関してこれらの変更を実装するには、以下の行を追加します。

com.collation.Topology.jvmargs.ibm=-Xk8300

v フラグメント化の問題に対処するもう一つの方法は、ラージ・オブジェクト (>64K) に対して具体的に一定のスペースを割り振ることです。 -Xloratio パラメーターを使用します。例:

– -Xloratio0.2

このコマンドは、アクティブな Java ヒープの x% (-Xmx の x% ではなく、Java ヒープの現行サイズの x%) を、ラージ・オブジェクト (≥64 KB) の割り振り専用に予約します。これを変更した場合、小さなオブジェクト用の領域サイズが縮小されないようにするために、-Xmx を変更する必要があります。このパラメーターの適正設定値を判別する方法としては、ヒープ・ダンプの分析が最適です。

このほかにも、Java のパフォーマンスに影響を与える、設定可能なパラメーターがいくつかあります。既存の JVM オプションを別の値に変更するには、以下のいずれかのファイルを編集します。

v TADDM 7.3.0 でドメイン・サーバーの場合は $COLLATION_HOME/deploy-tomcat/ROOT/WEB-INF/cmdb-context.xml ファイル

v TADDM 7.3.0.1 以降でドメイン・サーバーの場合は $COLLATION_HOME/apps/ROOT/WEB-INF/cmdb-context.xml ファイル

v TADDM 7.3.0 で同期サーバーの場合は $COLLATION_HOME/deploy-tomcat/ROOT/WEB-INF/ecmdb-context.xml ファイル

v TADDM 7.3.0.1 以降で同期サーバーの場合は $COLLATION_HOME/apps/ROOT/WEB-INF/ecmdb-context.xml ファイル

v TADDM 7.3.0 でディスカバリー・サーバーの場合は $COLLATION_HOME/deploy-tomcat/ROOT/WEB-INF/discovery-server-context.xml ファイル

v TADDM 7.3.0.1 以降でディスカバリー・サーバーの場合は$COLLATION_HOME/apps/ROOT/WEB-INF/discovery-server-context.xmlファイル

v TADDM 7.3.0 でストレージ・サーバーの場合は $COLLATION_HOME/deploy-tomcat/ROOT/WEB-INF/storage-server-context.xml ファイル

v TADDM 7.3.0.1 以降でストレージ・サーバーの場合は $COLLATION_HOME/apps/ROOT/WEB-INF/storage-server-context.xml ファイル

これらのいずれかのファイルを編集していずれかの TADDM サービスの設定を変更するには、最初にファイル内でそのサービスを見つけます。XML ファイル内のサービス定義の開始部分の例を以下に示します。

<bean id="Discover"class="com.collation.platform.service.ServiceLifecycle" init-method="start"destroy-method="stop"><property name="serviceName"><value>Discover</value></property>

定義内には、JVM の引数を制御するいくつかの要素および属性があります。例:


<property name="jvmArgs"><value>-Xms8M;-Xmx512M;-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider</value></property>

JVM の引数は、以下の要素にセミコロン区切りのリストとして設定することができます。

<property name="jvmArgs"><value>

collation.properties ファイルにある JVM プロパティーを変更することもできます。これらのプロパティーの形式は以下のいずれかです。

com.collation.JVM.jvmargs.VENDORこの種のプロパティーは、*-config.xml ファイルから読み取られる値に追加されます。

com.collation.jvmargs.VENDORこの種のプロパティーはすべての TADDM JVM に追加されます。

com.collation.JVM.jvmargsこの種のプロパティーは、*-config.xml ファイルに指定されているすべての値を上書きします。

ここで、

v JVM は、Proxy、Topology、EventsCore、ExcmdbCore、DiscoverAdmin、StorageService、DiscoveryService です。

v VENDOR は、ibm または sun です。

Java 仮想マシン・プロパティーのチューニングcollation.properties ファイルでは、TADDM ディスカバリー管理コンソールに適用される Java 仮想マシン (JVM) プロパティーのデフォルト値は、ご使用の環境内のサーバー等価物 (SE) の数を基準にしています。

ディスカバリー管理コンソールに適用される JVM プロパティーのデフォルト値v 小規模環境 (1000 個未満の SE):

– com.collation.gui.initial.heap.size=128m

– com.collation.gui.max.heap.size=512m

v 中規模環境 (1000 から 2500 個までの SE):



v 大規模環境 (2500 から 5000 個までの SE):



ネットワークのチューニングネットワークの帯域幅が 50% を超えて消費されないようにするには、システムの実装後にネットワークをモニターする必要があります。

管理 171

ネットワークはアプリケーションのパフォーマンス全体に影響する可能性がありますが、通常、以下の状況で遅延時間が発生した場合に、パフォーマンス上の要因になっています。

v クライアント・システムがサーバーに要求を送信してから、サーバーがこの要求を受信するまでの遅延時間。

v サーバー・システムがクライアント・システムにデータを返信してから、クライアント・システムがそのデータを受信するまでの遅延時間。

DNS のチューニングTADDM は、デプロイされた DNS インフラストラクチャーのパフォーマンスに依存します。DNS のパフォーマンスが他のアプリケーションにとっては十分である場合でも、TADDM 用にパフォーマンスを最適化するために、いくつかの構成が必要な場合があります。

TADDM は、コンポーネントおよびイベントの意味のある表示名を解決するために、大量の DNS ルックアップ照会を実行します。他のほとんどのアプリケーションとは異なり、TADDM は、正引きルックアップ (名前から IP アドレスへのマッピング) でなく、逆引きルックアップ (IP アドレスから名前へのマッピング) を主に使用します。

この使用パターンのため、DNS パフォーマンスに関する問題が TADDM パフォーマンスに与える影響は、他のアプリケーションに与える影響より大きくなる場合があります。例えば、500 ミリ秒という DNS 応答時間は、一般的なアプリケーションにはほとんどの場合大きな影響を与えません。しかし TADDM の場合、大量のDNS 照会を実行するため、パフォーマンス上の顕著な問題を引き起こす可能性があります。さらに、他のアプリケーションは正引きルックアップのみを実行するので、逆引きルックアップの場合のパフォーマンス上の問題はほとんどのアプリケーションには影響しませんが、TADDM には影響することになります。

一般に、DNS サービスのすべての利用者にとって利点が得られるようにするには、DNS インフラストラクチャーのパフォーマンス上の問題に対処する必要があります。それができない場合、DNS のパフォーマンス上の問題が TADDM に与える影響を軽減できる方法がいくつかあります。

v 逆引きルックアップの in-addr.arpa 委任が正しく構成されていることを確認してください。委任上の問題があると、TADDM サーバーが、存在しないサーバーに到達しようとするため、逆引きルックアップ中に長い休止や停止が発生する原因になることがあります。このタイプの構成の問題は、逆引きルックアップを実行するアプリケーション (TADDM など) のみに影響します。

v TADDM サーバー・システムには少なくとも 1 つのキャッシュ/転送 DNS サーバーをセットアップし、TADDM サーバーがその DNS サーバーをルックアップに使用するように構成します。こうすることで、DNS ルックアップが、ゾーンの TTL ルールに基づいてローカル TADDM 環境にキャッシュされるようになります。このタイプのサーバーは、ステートレスであるため、必要な保守が最小限で済み、オーバーヘッドの追加を生むこともほとんどありません。

v TADDM サーバー・システムには少なくとも 1 つの DNS スレーブ・サーバーをセットアップし、TADDM サーバーがその DNS サーバーをルックアップに使用するように構成します。こうすることで、DNS ルックアップがローカル


TADDM 環境内で実行されるようになり、より広域の DNS インフラストラクチャーと通信する必要がなくなります。DNS スレーブ・サーバーは状態を自動的に保守するため、必要な保守が最小限で済み、オーバーヘッドの追加を生むこともほとんどありません。

v DNS の代わりに hosts ファイルを使用するなど、ルックアップの代替メソッドを使用します。(この方法ではかなりの保守要件が発生することがあります。)

注: java.security ファイル内のデフォルトの DNS キャッシュ・パラメーターを変更しないでください。キャッシュ・パラメーターは DNS のパフォーマンスに影響を及ぼす可能性はありますが、この構成ファイルに対する変更は、TADDM 保守フィックスの適用時には保持されません。代わりに、このトピックで説明した方法のいずれかを使用して DNS のパフォーマンスを最適化してください。

同期サーバーのチューニング同期サーバーのパフォーマンスは、データベース処理に大きく左右されるため、データベースの保守およびチューニングに非常に依存することになります。同期化処理でパフォーマンス上の問題が発生した場合は、データベースのチューニングに関する情報を参照し、特に、DB2 データベースのバッファー・プール設定、Oracle データベースのバッファー・キャッシュ設定、およびデータベース保守に関する情報に注意してください。

特に同期サーバー用に、以下のコマンドを入力して DB2 データベース構成を更新します。

UPDATE DATABASE CONFIG FOR TADDM USINGUTIL_HEAP_SZ 5000LOGBUFSZ 1024LOCKLIST 20000SORTHEAP 2048PCKCACHESZ AUTOMATIC

;

Windows システムのチューニングTADDM サービス用にさらにメモリーを割り当てるには、Windows システムをチューニングします。

以下のタスクを実行します。

v システム用のページング・ファイルは、オペレーティング・システムと同じドライブ上に配置するべきではありません。可能であれば、システム用のページング・ファイルを別のディスク・ドライブ上に配置します。

v データベースおよびアプリケーション・サーバーを、ネットワーキング・アプリケーション用のデータを最大化するように構成します。

レポート作成カスタム・レポートを作成し、外部レポート・ビューアー、JSP レポート・ビューアー、または BIRT レポート作成システムを使用してそれをデータ管理ポータルに追加できます。

管理 173

外部レポート・ビューアー外部レポート・ビューアーを使用して、レポートを生成する外部プログラムを実行します。外部プログラムは、コマンド行を介した TADDM API を使用してデータにアクセスします。次に、レポートがユーザー・インターフェースに表示されます。

外部レポート・ビューアー・ロジックの作成外部レポートは実行可能プログラムの内部にインプリメントできます。例として、Perl スクリプト、シェル・スクリプト、または Java プログラムがあります。外部プログラムは、作成されるレポートがデータ管理ポータルに表示されるように、標準出力を介して有効な HTML ファイルを出力する必要があります。


外部レポート・ビューアーの一般的なインプリメンテーションでは、シェル・スクリプトを使用して TADDM API を照会し、その照会の XML 結果を一時ファイルに出力します。次に、シェル・スクリプトは XSLT プロセッサーを始動して照会結果を HTML 出力に変換します。これが STDOUT への出力となります。

重要: TADDM API を使用する外部レポート・ビューアーは、コマンド行プログラム api.sh スクリプト (Linux および UNIX の場合) および api.bat ファイル(Windows の場合) に資格情報を提供する必要があります。資格情報は api.sh スクリプトおよび api.bat に対するコマンド行引数であるため、これらはプロセス・リストを介してシステムの他のユーザーに表示されることもあります。機密パスワードを開示しないようにするには、外部生成されたレポートに表示されるオブジェクトに対して読み取り権限を持つダミー・アカウントをセットアップすることが役立ちます。

以下の例は、外部レポート bourne シェル・スクリプトの単純なインプリメンテーションを示しています。以下の内容を新規のファイル $COLLATION_HOME/sdk/bin/appServers.sh にコピーし、TADDM サーバーが実行しているユーザーがそのファイルを読み取り、実行できるようにします。

#!/bin/sh# Set environment variables for called scriptsexport COLLATION_HOME=/opt/ibm/taddm/dist

# Invoke the query via API and output to $COLLATION_HOME/sdk/bin/appServers.xml# NOTE: Change 'restrictedUser' and 'restrictedPassword' to your dummy account# credentials.sh $COLLATION_HOME/sdk/bin/api.sh -l log -H localhost -u restrictedUser -prestrictedPassword ¥ find AppServer > $COLLATION_HOME/sdk/bin/appServers.xml

# Invoke the XSLT processorsh $COLLATION_HOME/sdk/bin/xslt.sh -XSL $COLLATION_HOME/sdk/bin/appServers.xsl

以下の例は、シェル・スクリプトによって生成された appServers.xml ファイルを変換するために使用される appServers.xsl スタイル・シートです。レポートにはアプリケーション・サーバー名とその製品バージョンが表示されています。この内容を新規のファイル $COLLATION_HOME/sdk/bin/appServers.xsl にコピーし、TADDM サーバーが実行しているユーザーがそのファイルを読み取ることができるようにします。


<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version = '1.0' xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:coll="urn:www-collation-com:1.0" xmlns:xhtml="http://www.w3.org/1999/xhtml">

<xsl:variable name="nl"><xsl:text></xsl:text></xsl:variable>

<xsl:variable name="pageheadertext">Simple Application Server report

</xsl:variable>

<xsl:variable name="pagefootertext">End Simple Application Server report

</xsl:variable>

<xsl:template match="/"><html>

<head><link rel="stylesheet" type="text/css" media="all"

href="styles.css" /></head>

<body><h3>

<xsl:value-of select="$pageheadertext"/></h3>

<table border="1" width="100%"><tr>

<th>Product Version/th><th>Name/th>

</tr>

<xsl:apply-templates select="document('appServers.xml')/coll:results"/></table>

<xsl:value-of select="$nl"/></body></html></xsl:template>

<xsl:template match="coll:AppServer"><tr><td>xsl:value-of select="coll:productVersion"/></td><td>xsl:value-of select="coll:displayName"/></td>

</tr></xsl:template>

</xsl:stylesheet>

レポート・ロジックをテストするには、コマンド行から appServer.sh スクリプトを実行します。有効な HTML 出力が表示されます。

データ管理ポータルへの外部レポート・ビューアーの追加reports.xml ファイルを変更することにより、レポートがデータ管理ポータルに追加されます。 reports.xml ファイルは $COLLATION_HOME/etc/cdm/xml/ ディレクトリーにあります。

手順

データ管理ポータルに外部レポート・ビューアーを追加するには、以下のステップを実行します。

1. テキスト・エディターを使用して、$COLLATION_HOME/etc/cdm/xml/reports.xml

ファイルを開きます。

管理 175

2. reports.xml ファイルで、レポート定義のレポート・ディスクリプター、レポート・グループ、レポート名、および外部スクリプトを指定します。以下の例では、Inventory Reports グループにある、Application Servers という名前の外部レポートを作成する方法を示しており、sdk/bin/appServers.sh ファイルが指定されています。

<bean class="com.collation.cdm.reports.viewer.ExternalReportViewer" id="AppServers1"><property name="reportGroup"><value>Inventory Reports</value></property><property name="reportName"><value>Application Servers</value></property><property name="script"><value>sdk/bin/appServers.sh</value></property></bean>

3. $COLLATION_HOME/etc/cdm/xml/reports.xml ファイルを保存します。

4. レポートがデータ管理ポータルに表示されます。

JSP レポート・ビューアーJSP レポート・ビューアーは、Java Server Pages (JSP) オーサリングの知識を持つユーザーに、さらなる柔軟性とセキュリティーを提供します。レポート・ロジック(API アクセスを含む) は JSP ページに配置され、その後、データ管理ポータルによってレンダリングされます。 JSP レポート・ビューアーを使用する場合、セキュリティー資格情報がログイン・ユーザーから自動的に継承されます。

JSP レポート・ビューアー・ロジックの作成JSP レポート・ビューアーのロジックは、データ管理ポータルによって呼び出される JSP に含まれています。 JSP レポートの一般的なインプリメンテーションでは、TMSDataHelper と呼ばれる Java ヘルパー・クラスを使用して、TADDM APIを照会します。照会の結果は、Java メソッドを使用して扱うことができるオブジェクトです。TADDM API およびモデルについて詳しくは、$COLLATION_HOME/sdk/

doc にある SDK の資料を調べてください。


以下の例は、JSP レポート・ビューアーの単純なインプリメンテーションを示しています。以下の内容を新規ファイル $COLLATION_HOME/deploy-tomcat/reports.war/WEB-INF/view/custom.jsp (TADDM 7.3.0 を使用する場合) または$COLLATION_HOME/apps/reports.war/WEB-INF/view/custom.jsp (TADDM 7.3.0.1 以降を使用する場合) にコピーし、そのファイルを TADDM サーバーの実行ユーザーが読み取ったり、実行したりできるようにします。

以下の例は、シェル・スクリプトによって生成された appServers.xml ファイルを変換するために使用される appServers.xsl スタイル・シートを示しています。レポートにはアプリケーション・サーバー名とその製品バージョンが表示されています。この内容を新規のファイル $COLLATION_HOME/sdk/bin/appServers.xsl にコピーし、TADDM サーバーを実行しているユーザーがそのファイルを読み取ることができるようにします。

<%@ page language="java" %><%@ page import="com.collation.cdm.common.util.TMSDataHelper" %><%@ page import="java.lang.StringBuffer" %><%@ page import="com.collation.cdm.reports.util.ReportsParser" %><%@ page import="com.collation.cdm.common.util.TMSReportingTransformer" %><%@ page import="com.collation.platform.model.AttributeNotSetException" %><%@ page import="com.collation.platform.model.ModelObject" %><%@ page import="com.collation.platform.model.topology.sys.ComputerSystem" %><%@ page import="com.collation.platform.model.topology.process.BusinessProcess" %>


<%@ page import="com.collation.platform.model.topology.process.Activity" %><%@ taglib prefix="x" uri="http://java.sun.com/jstl/xml" %><%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %><%@ page import="com.collation.platform.util.Props" %><%@ page import="java.util.ArrayList"%><%@ page import="com.collation.cdm.common.messages.CdmLocalizedMessages"%><%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %><%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %><%java.util.Locale locale =com.collation.cdm.common.util.CDMUtil.checkLocale(request.getLocale());

if (null == session.getAttribute(org.apache.struts.Globals.LOCALE_KEY)) {session.setAttribute(org.apache.struts.Globals.LOCALE_KEY, locale);

}%><%//TMSDataHelper is a utility class for running MQL queries against the DBTMSDataHelper tms = new TMSDataHelper(locale);

//Perform a query for all ComputerSystemsModelObject dataIn[] = tms.doModelObjectQuery("SELECT * FROM ComputerSystem",null);

//Build an HTML report based on the API outputStringBuffer output = new StringBuffer();output.append("<p>");output.append("<table border=¥"1¥">");

int c = 0;int s = dataIn.length;while (cs) {

ComputerSystem tmo = (ComputerSystem)dataIn[c];String csName = null;String csLabel = null;if (tmo.hasName()) {

try {csName = tmo.getName();

} catch (AttributeNotSetException e) {csName = "unknown";

}}if (tmo.hasSignature()) {

try {csLabel = tmo.getSignature();

} catch (AttributeNotSetException e) {csLabel = "";

}}output.append("<tr><td colspan=¥"2¥" bgcolor=¥"#9999FF¥">");output.append("ComputerSystem" + "<br>");output.append(" Name: " + csName + "<br>");output.append("</td><td>");output.append("Signature: " + csLabel);output.append("</td></tr>");c++;

}output.append("</table>");String bpstring = output.toString();%><html><body><h1>Sample JSP Report/h1><%=bpstring%></body></html>

管理 177

データ管理ポータルへの JSP レポート・ビューアーの追加reports.xml ファイルを変更することにより、レポートがデータ管理ポータルに追加されます。 reports.xml ファイルは $COLLATION_HOME/etc/cdm/xml/ ディレクトリーにあります。

手順

データ管理ポータルに JSP レポート・ビューアーを追加するには、以下のステップを実行します。

1. テキスト・エディターを使用して、$COLLATION_HOME/etc/cdm/xml/reports.xml

ファイルを開きます。

2. reports.xml ファイルで、レポート定義のレポート・ディスクリプター、レポート・グループ、レポート名、および外部スクリプトを指定します。以下の例では、Inventory Reports グループにある、Custom Report という名前の外部レポートを作成する方法を示しており、/WEB-INF/view/custom.jsp スクリプトが指定されています。

<bean class="com.collation.cdm.reports.viewer.JSPReportViewer" id="CustomReport"><property name="reportGroup"><value>Inventory Reports</value></property><property name="reportName"><value>Custom Report</value></property><property name="script"><value>/WEB-INF/view/custom.jsp</value></property></bean>

3. $COLLATION_HOME/etc/cdm/xml/reports.xml ファイルを保存します。

4. レポートがデータ管理ポータルに表示されます。

Tivoli Common Reporting でのレポート作成BIRT レポート・ビューアーでの BIRT レポートの表示は安全ではないため、デフォルトで使用不可になっており、TADDM の BIRT レポートを Tivoli CommonReporting にインポートできるようになっています。これにより、TADDM データを含む製品間共通レポートが使用可能になります。また、レポート・スケジューリングなどの Tivoli Common Reporting 機能を使用したり、Tivoli CommonReporting をレポートの中央リポジトリーとして使用したりすることもできます。

一部のタスクでは、使用している Tivoli Common Reporting のバージョンや使用しているデータベースによって、実行するステップが異なります。

Fix Pack 1

TADDM 7.3 フィックスパック 1 以降がインストールされている場合

は、ベスト・プラクティス・ガイド「The enhanced Cognos model in TADDM7.3 FPx」も参照してください。

Tivoli Common Reporting の概要Tivoli Common Reporting ツールは、特定の Tivoli 製品に付属のレポート作成機能です。このツールは、複数の製品で一貫したルック・アンド・フィールを持つレポートを集中して表示および管理するための方法となります。

Tivoli Common Reporting には、レポートを保管および編成するためのデータ・ストア、およびレポートの管理、実行、スケジューリング、表示を行うためのインターフェースが組み込まれています。 Tivoli Common Reporting は、Cognos® とBIRT の両方のランタイム・エンジンを使用します。


https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d5ebce8-2dd8-449c-a58e-4676134e3eb8#fullpageWidgetId=Wea1cb2531f10_4ccd_99d7_6ab0334cb21f&file=0fc2ec6f-ca45-43fc-bb3c-d23b52ca01c7

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d5ebce8-2dd8-449c-a58e-4676134e3eb8#fullpageWidgetId=Wea1cb2531f10_4ccd_99d7_6ab0334cb21f&file=0fc2ec6f-ca45-43fc-bb3c-d23b52ca01c7

重要: Tivoli Common Reporting は、IBM Jazz™ for Service Management インストール・ディスク上で提供されます。IBM Jazz for Service Management をインストールする予定がない場合は、統合 BIRT レポート機能を使用できます。

システムに Tivoli Common Reporting がすでにインストールされている場合には、オプションで、Tivoli Common Reporting と互換性のある定義済み TADDMレポートをインポートできます。これにより、Tivoli Common Reporting をTivoli 製品レポートの中央リポジトリーとして使用できるようになります。また、製品間共通レポート、役割ベースのセキュリティー、レポート・スケジューリングなどの拡張レポート作成オプションを使用することもできます。


注: TADDM を IBM Tivoli Change and Configuration Management Database(CCMDB) または IBM SmartCloud Control Desk と共に使用する場合は、CCMDB または IBM SmartCloud Control Desk の資料を参照し、サポートされるTivoli Common Reporting のバージョンについて確認してください。

Tivoli Common Reporting について詳しくは、https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9caf63c9-15a1-4a03-96b3-8fc700f3a364 にアクセスしてください。

Tivoli Common Reporting と IBM Cognos Framework ManagerのインストールTivoli Common Reporting および IBM Cognos Framework Manager をインストールする必要があります。

手順

Tivoli Common Reporting および IBM Cognos Framework Manager をインストールするには、次の手順を実行します。

1. 表示されたデフォルトのオプションを使用して、Tivoli Common Reporting をインストールします。 Oracle データベースを使用する場合は、TivoliCommon Reporting 2.1 または 3.1 を使用する必要があります。

2. CognosModeling フォルダー内にある IBM Cognos Framework Manager パッケージをインストールします。表示されたデフォルトのオプションを使用してください。

3. 使用可能な場合、CognosModelingFix フォルダー内にあるセキュリティー・パッチもインストールします。表示されたデフォルトのオプションを使用してください。

データベース・クライアントのインストールおよび構成TADDM データベース・サーバー以外のコンピューターに Tivoli CommonReporting をインストールした場合は、データベースに接続するためのデータベース・クライアントをインストールする必要があります。TADDM データベース・タイプに応じて、DB2 データベース・クライアントか Oracle データベース・クライアントのいずれかを使用できます。 TADDM データベースと同じサーバーに

管理 179

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=9caf63c9-15a1-4a03-96b3-8fc700f3a364



Tivoli Common Reporting をインストールした場合は、データベース・クライアントをインストールする必要はありません。

手順

データベース・クライアントをインストールおよび構成するには、以下のステップを実行します。

以下のいずれかの操作を実行します。

v DB2 データベース・クライアントを使用する場合は、以下のステップを実行します。

1. 表示されたデフォルトのオプションを指定して、TCR がインストールされているマシンに DB2 クライアントをインストールします。

2. TADDM データベースがカタログされていることを確認します。このステップは、Tivoli Common Reporting が、DB2 クライアントを使用して DB2サーバーに正常に接続するために必要です。

v Oracle データベース・クライアントを使用する場合は、以下のステップを実行して、Oracle Universal Installer ウィザードおよび Oracle Net ConfigurationAssistant ウィザードを使用してインストールおよび構成を行います。

1. Oracle Universal Installer ウィザードの「インストール・タイプの選択」ページで、インストール・モードとして「管理者」を選択します。

2. 「ホームの詳細の指定」ページで、インストールの名前と、製品のインストール先の場所へのパスを指定します。

3. 「製品固有の前提条件のチェック」ページで、インストールおよび構成のそれぞれの要件が満たされていることを確認します。それぞれの確認ステータスが「成功しました」になるまで、インストールを続行しないでください。

4. Oracle Net Configuration Assistant ウィザードの「ようこそ」ページで、「標準構成の実行」チェック・ボックスが選択されていないことを確認します。

5. 「ネーミング・メソッド構成 - メソッドの選択」ページで、ネーミング・メソッドとして「ローカル・ネーミング」を設定します。

6. 「ネット・サービス名の構成 - サービス名」ページで、ご使用のリモートOracle データベース・サーバーのサービス名を入力します (例えば、ORCL)。

7. 「ネット・サービス名の構成-プロトコルの選択」ページで、データベースへの接続に使用するプロトコルとして「TCP」を選択します。

8. 「ネット・サービス名の構成 - TCP/IP プロトコル」ページで、データベースが実行されているコンピューターのホスト名を入力します。「標準ポート番号の 1521 を使用」を選択します。

9. 「ネット・サービス名の構成 - テスト」ページで、「はい。テストを実行します。」を選択します。

ご使用のデータベース・ユーザー名とパスワードが正しい場合は、以下のテキストが表示されます。

Connecting... Test successful.


データベースに正しく接続できない場合は、ログイン資格情報を変更しなければならない場合があります。データベースのログイン資格情報を変更するには、「ログインの変更」をクリックして、有効なデータベース・ユーザー名とパスワードを指定してください。

10. 「ネット・サービス名の構成 - ネット・サービス名」ページで、デフォルトのサービス名を受け入れます。これは、以前に指定したサービス名のはずです。

11. TNS_ADMIN という名前の Windows システム変数を作成して、この値をtnsnames.ora ファイルが入っているフォルダーへの絶対パスに設定します。インストール中に tnsnames.ora ファイルが %ORACLE_HOME%/client_1/NETWORK/ADMIN フォルダー (例: C:/oracle/product/10.2.0/client_1/

NETWORK/ADMIN) に作成されます。

12. startTCRserver.sh/bat スクリプトの TNS_ADMIN 変数を、tnsnames.ora ファイルの場所 (例: %ORACLE_HOME%/client_1/NETWORK/ADMIN) を指すように設定します。

13. 新しいシステム変数を確実に有効にするために、コンピューターをリブートします。

IBM Cognos Framework Manager の構成IBM Cognos 10 Framework Manager のプロパティーを適切な値で更新する必要があります。


注: 次の手順は、Tivoli Common Reporting 3.1 用の IBM Cognos 10 FrameworkManager の構成にあてはまります。ただし、これは Tivoli Common Reporting2.1 用の IBM Cognos 8 Framework Manager と同じです。

Tivoli Common Reporting をインストールすると、IBM Cognos Configuration プログラムがインストールされ、一部のプロパティー値が更新されます。 IBMCognos 10 Framework Manager をインストールすると、IBM CognosConfiguration プログラムの別のバージョンがインストールされますが、すべてのプロパティーが更新されるわけではありません。IBM Cognos Configuration のTivoli Common Reporting バージョンの一部のプロパティー値を、IBM CognosConfiguration の IBM Cognos 10 Framework Manager バージョンに手動でコピーする必要があります。

手順

IBM Cognos 10 Framework Manager を構成するには、次の手順を実行します。

1. Tivoli Common Reporting によってインストールされた IBM CognosConfiguration のバージョンを開きます。このプログラムを開くには、「スタート」 > 「プログラム」 > 「Tivoli Common Reporting 3.1」 > 「IBMCognos Configuration」をクリックします。

2. IBM Cognos 10 によってインストールされた IBM Cognos Configuration のバージョンを開きます。このプログラムを開くには、「スタート」 > 「プログラム」 > 「IBM Cognos 10」 > 「IBM Cognos Configuration」をクリックします。

管理 181

3. IBM Cognos Configuration のバージョンごとに、「ローカル構成」 > 「環境」をクリックします。

4. IBM Cognos Configuration の Tivoli Common Reporting バージョンの「ゲートウェイ URI」プロパティーの値を、IBM Cognos Configuration の IBMCognos 10 バージョンの「ゲートウェイ URI」プロパティーにコピーします。URI の構文は http://tcrhost:16310/tarf/servlet/dispatch です。

5. IBM Cognos Configuration の Tivoli Common Reporting バージョンの「外部ディスパッチャー URI」プロパティーの値を、IBM Cognos Configurationの IBM Cognos 10 バージョンの「外部アプリケーション用ディスパッチャーURI」プロパティーにコピーします。URI の構文は http://tcrhost:16310/tarf/servlet/dispatch です。

6. IBM Cognos Configuration の IBM Cognos 10 バージョンに加えた変更を保存します。

TADDM モデルの生成

Fix Pack 1

TADDM データベース・コンテンツの最新のスナップショットを入手するために、TADDM モデルを生成できます。これには、すべての拡張属性の定義が含まれます。拡張属性を使用しない場合は、この手順をスキップして、事前作成されたTADDM Cognos モデル・ファイル ($COLLATION_HOME/etc/reporting/tcr/model.xml ファイル) を使用できます。

始める前に

生成された TADDM モデルには、TADDM がサポートするすべての共通データ・モデルのクラスと、TADDM データベースに保管された拡張属性の定義が含まれています。TADDM モデルは、Tivoli Common Reporting サーバーで公開して、Cognos レポートで使用できます。TADDM モデルの生成は、何度でも行うことができます。モデルを再生成するたびに、更新された TADDM データベースの内容が含められます。

注:

v TADDM モデルが Tivoli Common Reporting サーバーで公開された後に、拡張属性の定義が TADDM データベースから削除された場合は、それらの定義を使用する Cognos レポートが機能しなくなる可能性があります。

v Windows オペレーティング・システムを使用している場合は、以下の手順で使用されているスクリプトの拡張子を .sh から .bat に変更してください。

手順

1. TADDM サーバーで、$COLLATION_HOME/bin ディレクトリーを開きます。

2. 以下のステップを実行して、拡張属性ビューをリフレッシュします。

a. 拡張属性ビューを作成している場合は、以下のコマンドを実行してそのビューを削除します。

./extattr_views.sh remove

b. 以下のコマンドを実行して、拡張属性ビューの定義を含む SQL スクリプトを生成します。


./extattr_views.sh scripts

c. 以下のコマンドを実行して、生成した SQL スクリプトを使用して拡張属性ビューを作成します。

./extattr_views.sh create

3. Cognos モデル・ファイルを生成するには、以下のコマンドを実行します。

./genCognosModel.sh

生成された TADDM モデルは、model.xml ファイルに保管され、このファイルが ■$COLLATION_HOME/etc/reporting/tcr ディレクトリーに配置されます。コマンドのログ・メッセージは、$COLLATION_HOME/log/genCognosModel.log ファイルに出力されます。

次のタスク

IBM Cognos Framework Manager を使用して、生成した TADDM モデルをTivoli Common Reporting サーバーで公開できます。詳しくは、 188 ページの『IBM Cognos Framework Manager を使用したモデルの公開』を参照してください。

拡張属性ビューについて詳しくは、TADDM の「SDK 開発者ガイド」の『拡張属性ビュー』トピックを参照してください。

Tivoli Common Reporting へのモデルおよびサンプル・レポートのインポートサンプル TADDM レポートを Tivoli Common Reporting バージョン 2.1 および3.1 にインポートできます。


この手順は、Tivoli Common Reporting バージョン 2.1 にあてはまります。

手順

Tivoli Common Reporting 2.1 にモデルおよびサンプル・レポートをインポートするには、次の手順を実行します。

1. TADDM サーバーから Tivoli Common Reporting サーバーのTCRComponent/cognos/deployment フォルダーに、$COLLATION_HOME/etc/

reporting/TADDMPackage.zip パッケージをコピーします。

2. Tivoli Common Reporting のホーム・ページを開きます。

3. 「レポート作成」 > 「Common Reporting」をクリックします。

4. 「起動」メニューから、「管理」を選択します。「管理」ペインが表示されます。

5. 「構成」タブをクリックします。

6. 「新規インポート」アイコンをクリックします。「新規インポート」ウィザードが表示されます。

7. 使用可能なパッケージのリストから、「TADDMPackage」を選択します。「次へ」をクリックします。

管理 183

8. オプション: 「説明」フィールドに、パッケージの説明を入力します。「次へ」をクリックします。

9. パッケージ名の横のチェック・ボックスを選択します。

10. 「オプション」セクションで、「ソースの所有者」と「新規エントリーと既存エントリー」をクリックします。「記録レベル」メニューから、「基本」を選択します。「次へ」をクリックします。

11. 「保存して 1 回実行」をクリックします。「次へ」をクリックします。


この手順は、Tivoli Common Reporting バージョン 3.1 にあてはまります。

手順

Tivoli Common Reporting 3.1 にモデルおよびサンプル・レポートをインポートするには、次の手順を実行します。

1. TADDM サーバーから JazzSM インストール済み環境のreporting/cognos/deployment フォルダーに $COLLATION_HOME/etc/reporting/TADDMPackage.zip パッケージをコピーします。



4. 「起動」メニューから、「IBM Cognos Administration」を選択します。「管理」ペインが表示されます。


6. 「コンテンツ管理」に移動します。「新規インポート」アイコンをクリックします。「新規インポート」ウィザードが表示されます。

7. 使用可能なパッケージのリストから、「TADDMPackage」を選択します。「次へ」をクリックします。

8. オプション: 「説明」フィールドに、パッケージの説明を入力します。「次へ」をクリックします。

9. パッケージ名の横のチェック・ボックスを選択します。「次へ」をクリックします。

10. 「エントリーの所有者」セクションで、「ソースの所有者」と「新規エントリーと既存エントリー」をクリックします。「配布記録」セクションの「記録レベル」メニューから、「基本」を選択します。「次へ」をクリックします。

11. 指定した値が正しいことを確認します。「次へ」をクリックします。

12. 「保存して 1 回実行」をクリックします。「完了」をクリックします。

13. 「実行」をクリックします。

TADDM モデルのデータ・ビューTADDM データ・モデル・ファイル (model.xml ファイル) からレポートを生成できます。

データ・モデルは、複数の名前空間から編成されています。名前空間とは、含まれるすべての名前が一意である論理コンテナーです。各名前空間には照会サブジェク


ト、照会項目、およびオブジェクトが含まれています。 TADDM model.xml ファイルをインポートすると、以下の名前空間が使用可能になります。

Fix Pack 1

CDM 名前空間

これらのビューには、ディスカバリー関連のクラスを含む、共通データ・モデルのほぼすべてのクラスの照会サブジェクトが、パッケージ名ごとにいくつかの名前空間に分割されて含まれています。パッケージ名は、アルファベット順にソートされます。単純モデルのクラスは、名前空間名の simple というプレフィックスで識別されます。このデータを使用すると、さまざまなタイプの CDM オブジェクトを含むレポートを生成できます。

CDM 名前空間の照会サブジェクトには、Parent 属性に関連する定義済みの関係が含まれています。例えば、app.j2ee.J2EEDomain クラスには、app.j2ee.J2EEServer[] タイプの属性 Servers が含まれています。また、app.j2ee.J2EEServer クラスには、app.j2ee.J2EEDomain タイプの属性Parent が含まれています。このため、CDM クラスのすべての互換ペアには、以下のような定義済みの関係があります。

v app.j2ee.J2EEDomain [0..1] - [0..n] app.j2ee.J2EEServer

v app.j2ee.J2EEDomain [0..1] - [0..n] app.j2ee.jboss.JBossServer

v app.j2ee.J2EEDomain [0..1] - [0..n]

app.j2ee.weblogic.WebLogicServer

v app.j2ee.jboss.JBossDomain [0..1] - [0..n]

app.j2ee.jboss.JBossServer

v app.j2ee.websphere.WebSphereCell [0..1] - [0..n]

app.j2ee.websphere.WebSphereServer

TADDM 7.3.0.1 では、CDM 名前空間の一部の照会サブジェクトは、配列型の非永続属性に対して定義されています。TADDM 7.3.0.2 では、照会サブジェクトは配列型のすべての属性に対して定義されています。これらの照会サブジェクトの名前は、"[配列属性を宣言するクラスの名前]-->[配列属性の名前]" という形式になっています。例えば、simple.SGroup クラスには、ModelObject[] タイプの GroupMembers 属性があるため、照会サブジェクトは "SGroup-->GroupMembers" となります。これらの照会サブジェクトには、記載された配列属性と、これらの属性を含むすべての CDM クラスとの間の、定義済みの関係が含まれています。例えば、前述のGroupMembers 属性については、さまざまな関係の一部として以下の関係が定義されています。

v simple.SGroup [1..1] - [0..n] simple."SGroup-->GroupMembers"

v simple.SBaseCollection [1..1] - [0..n] simple."SGroup--

>GroupMembers"

v app.biztalk.BizTalkGroup [1..1] - [0..n] simple."SGroup--

>GroupMembers"

v app.hacmp.HACMPResourceGroup [1..1] - [0..n] simple."SGroup--

>GroupMembers"

配列型の属性を使用するには、配列型の属性と必要な CDM クラスとの間に、その PK_C 属性を使用して関係を定義する必要があります。一方で、配

管理 185

列型の非永続属性 (ModelObject[]) を使用する場合は、その Guid 属性を使用します。例えば、以下のとおりです。

v Fix Pack 2 sys.ComputerSystem オブジェクトの ZReportfiles としてsys.zOS.ZReportFile オブジェクトを示す Cognos レポートを作成するには、IBM Cognos Report Studio で、以下の列の間に結合を定義する必要があります。

sys."ComputerSystem-->ZReportfiles".PK__ZReportfiles_C[0..n]-[0..1] sys.zOS.ZReportFile.PK_C

v simple.SBaseCollection オブジェクトの GroupMembers としてapp.AppServer オブジェクトを示す Cognos レポートを作成するには、IBM Cognos Report Studio で、以下の列の間に結合を定義する必要があります。

simple."SGroup-->GroupMembers".GroupMembersGuids [0..n]-[0..1] app.AppServer.Guid

Fix Pack 2 多くの場合、依存オブジェクトには対応する親属性があるため、配列型の属性用に手動で結合を作成する必要はありません。Cognos モデルにはそれらの関係が含まれています。例えば、sys.ComputerSystem オブジェクトの FileSystems として sys.FileSystem オブジェクトを示すレポートを作成するために、手動で結合を作成する必要はありません。これは、sys.FileSystem オブジェクトには、sys.ComputerSystem オブジェクトを指す親属性があるためです。

Fix Pack 3

TADDM 7.3.0.3 以降では、Cognos モデルには、タイム・スタ

ンプ・タイプのすべての属性に対して、Data Time タイプの照会項目が含まれています。例えば、sys.aix.AixUnitaryComputerSystem 照会サブジェクトには、以下の照会項目が含まれています。

v タイプ Int64 の LastStoredTime。ビルディング・ブロック・ビュー内の LASTSTOREDTIME_C 列を指します。列内の値の例:1445417251307。

v タイプ Data Time の LastStoredTimeT。ビルディング・ブロック・ビュー内の LASTSTOREDTIME_T 列を指します。列内の値の例: Oct 21,

2015 10:47:31 AM。

LastStoredTimeT 照会項目は、LastStoredTime 照会項目と同等ですが、UNIX エポック (長整数) ではなく協定世界時の形式で表されます。T サフィックスを含む照会項目は、元の長整数属性と同等のタイム・スタンプです。

WebSphere 名前空間

注: Fix Pack 1 WebSphere の名前空間は、TADDM 7.3.0.1 以降では推奨されません。このビューには、WebSphere 環境の 1 次照会サブジェクトが含まれています。 WebSphere 固有のレポート (WebSphere サーバーのプロパティーまたは JVM 設定のリストなど) を生成する場合にこのデータを使用できます。この WebSphere サーバー照会サブジェクトは、共有名前空間に含まれているアプリケーション・サーバー照会サブジェクトにリンクしています。WebSphere クラスターおよび WebSphere セル照会サブジェクトは、共有名


前空間に含まれているアプリケーション・サーバー・クラスターおよびJ2EE ドメイン照会サブジェクトにリンクしています。

共有名前空間

注: Fix Pack 1 共有の名前空間は、TADDM 7.3.0.1 以降では推奨されません。このビューには、キー・クラスと見なされ、異なる名前空間のデータを結合するブリッジとして使用できる照会サブジェクトが含まれています。共有名前空間には、コンピューター・システムとコレクション・クラスに関する情報が含まれています。このデータをインベントリー・レポートの作成に使用できます。

ビジネス・アプリケーションの名前空間

注: Fix Pack 1 ビジネス・アプリケーションの名前空間は、TADDM 7.3.0.1以降では推奨されません。このビューには、ビジネス・アプリケーションの照会サブジェクト (アプリケーションおよび機能グループの照会サブジェクト) が含まれています。機能グループ照会サブジェクトは、コレクション照会サブジェクトを介して共有名前空間にリンクしています。このデータをビジネス・アプリケーションとそのメンバーを表示するレポートの作成に使用できます。

データベース名前空間

注: Fix Pack 1 データベースの名前空間は、TADDM 7.3.0.1 以降では推奨されません。このビューには、データベースおよびデータベース・サーバーに関連する照会サブジェクトが含まれています。ベンダー固有のデータベース・レポートではなく、汎用データベース・レポートを生成するには、すべてのデータベースの照会サブジェクトを使用します。データベース・コンテンツは、アプリケーション・サーバー照会サブジェクトを介して共有名前空間にリンクしています。

依存関係および関係の名前空間

注: Fix Pack 1 依存関係および関係の名前空間は、TADDM 7.3.0.1 以降では推奨されません。このビューには、生成される関係と依存関係 (IP 依存関係、スイッチからデバイスへの接続関係など) を表す照会サブジェクトが含まれています。レポートまたは照会を作成するときに、汎用の関係 (未リンクの) 照会サブジェクトを使用してマニュアル・リンクを作成できます。スイッチからデバイスへの接続照会サブジェクトにより、スイッチを共有名前空間のコンピューター・システム・オブジェクトに結合できます。サーバー・アフィニティーに関連する 3 つの照会サブジェクトがあります。サーバー照会サブジェクトは、すべてのコンピューター・システム、アプリケーション・サーバー、およびデータベース内のサービス・オブジェクトの集合体を表します。アフィニティー (ターゲット・リンク) 照会サブジェクトは、各アフィニティー関係をサーバー照会サブジェクト内のそのターゲットに結合します。アフィニティー (ソース・リンク)照会サブジェクトは、各アフィニティー

管理 187

関係をサーバー照会サブジェクト内のそのソースに結合します。サーバー・コンテンツは、コンピューター・システム、アプリケーション・サーバー、およびサービスの照会サブジェクトを介して共有名前空間にリンクしています。ネットワーク内の構成アイテム間の関係を示す一般レポートを生成する場合にこのデータを使用できます。

IBM Cognos Framework Manager を使用したモデルの公開オブジェクトを TADDM データ・モデル (model.xml ファイル) に追加するには、そのファイルを編集し、IBM Cognos 10 Framework Manager を使用してインポートする必要があります。


次の手順は、IBM Cognos 10 Framework Manager にあてはまります。ただし、これは IBM Cognos 8 Framework Manager と同じです。

手順

IBM Cognos 10 Framework Manager を使用してデータ・モデルをインポートするには、次の手順を実行します。

1. IBM Cognos 10 Framework Manager を始動します。

2. 新規プロジェクトを作成します。

3. プロンプトが出されたら、Tivoli Common Reporting サーバーの資格情報を入力します。これらの資格情報の入力を求めるプロンプトが複数回表示される場合があります。

4. IBM Cognos 10 Framework Manager を閉じます。

5. TADDM サーバーから Cognos Framework のプロジェクト・フォルダーに、以下のファイルをコピーします。

$COLLATION_HOME/etc/reporting/tcr/model.xml

Cognos Framework のプロジェクト・フォルダー内の既存の model.xml ファイルを上書きします。

6. IBM Cognos 10 Framework Manager を始動し、前に作成したプロジェクトを開きます。

7. 「プロジェクト・ビューアー」ペインで、「データ・ソース」 >「content_manager_data_source_name」をクリックします。

8. ご使用の DB2 データベースの名前が Cognos データベース・ソースで定義された名前とは異なる場合は、「スキーマ」フィールドの内容を、TADDM データベースに使用されている DB2 インスタンス名で置き換えます。

9. プロジェクトを保存します。

10. 「プロジェクト・ビューアー」ペインで、「パッケージ」をクリックします。

11. パッケージ名を右クリックして、「パッケージの公開」を選択します。TADDM Cognos モデルの検証と公開には、数分かかることがあります。

Tivoli Common Reporting でのデータ・ソースの構成Tivoli Common Reporting を使用して、データ・ソースを構成できます。


始める前に

以下のいずれかの状況が満たされていることを確認してください。

v TADDM データベースがローカルでカタログされている。

v TADDM データベースをホストするサーバーで Tivoli Common Reporting が実行されている。

DB2 データベースを使用している場合は、スキーマ名が DB2 インスタンス名と一致していることを確認します。スキーマ名は、指定されるデータベースへのアクセスを許可するために使用される DB2 データベース名を指定します。 DB2 インスタンス名は、TADDM のインストール時に指定してあります。TADDM model.xml ファイルに指定されているデフォルトのインスタンス名は DB2INST1 です。必要に応じてスキーマの名前を変更してください。

Oracle データベースを使用している場合は、スキーマ名がブランクになっていることを確認します。

手順

Tivoli Common Reporting を使用してデータ・ソースを構成するには、以下のステップを実行します。



3. ご使用の Tivoli Common Reporting のバージョンに応じて、「起動」メニューから以下のいずれかのメニュー項目を選択します。

v バージョン 2.1 - 「管理」。

v バージョン 3.1 - 「IBM Cognos Administration」。

「管理」ペインが表示されます。


5. 「新規データ・ソース」アイコンをクリックします。「新規データ・ソース」ウィザードが表示されます。

6. 「名前」フィールドに、CMDBTCRを入力します。 CMDBTCR という名前がデータ・モデルで参照されているため、新しいデータ・ソースに同じ名前を付ける必要があります。

7. 「タイプ」メニューから、使用しているデータベースのタイプを選択します。

8. 以下のいずれかのステップを実行します。

v データベース・タイプが DB2 の場合、「DB2 データベース名」フィールドに、TADDM データベース名またはカタログされた TADDM データベースの別名を入力します。

v データベース・タイプが Oracle の場合、「SQL*Net 接続文字列」フィールドに、Oracle データベースのサービス名 (ORCL など) を入力します。Oracle データベースのサービス名は、Oracle Database Client の構成時に指定してあります。 Oracle データベースのサービス名は、%TNS_ADMIN%/tnsnames.ora ファイルで確認できます。次のストリングを見つけてください。

SERVICE_NAME =

管理 189

9. 「サインオン」セクションで、データベースのユーザー名とパスワードを指定します。

10. データベース接続をテストするには、「テスト」をクリックします。「新規データ・ソース」ウィザードの「結果の表示」ページに、テストの状況が表示されます。

Tivoli Common Reporting への TADDM レポート・パッケージのインポート定義済み TADDM レポートを Tivoli Common Reporting にインポートするには、TADDM レポート・パッケージをインポートできます。

始める前に

まず、Tivoli Common Reporting 機能をシステムにインストールする必要があります。 Tivoli Common Reporting は、一部の Tivoli 製品には付属していますが、現在 TADDM には組み込まれていません。


Tivoli Common Reporting レポート・パッケージは、1 つ以上のレポートまたはレポート設計がそれぞれに必要なリソースと一緒に Tivoli Common Reporting で使用可能な形式で含まれる .zip ファイルです。 TADDM 用に事前定義されたレポートは、Tivoli Common Reporting にインポート可能なレポート・パッケージに含まれています。

一部の BIRT レポートでは、レポートが実行されるサーバーによっては同一レポートの複数のバージョンが使用可能になります。例えば、ドメイン・サーバーまたはストレージ・サーバーの TADDM_SNAPSHOT_CHANGE レポート、同期サーバーの TADDM_SNAPSHOT_SYNC_CHANGE レポートなどです。一般に、レポートの適切なバージョンのみが使用可能ですが、BIRT レポートを Tivoli CommonReporting にインポートした後に、レポートの両方のバージョンが使用可能になることがあります。レポートを実行するサーバーで適切なレポート・バージョンのみを使用するようにしてください。

BIRT レポートを Tivoli Common Reporting にインポートした後で、レポート名に「ドリルスルーのみ」というテキストが含まれているレポートが使用可能になることがあります。これらのレポートは、別のレポートで選択されているデータをドリルダウンすることで実行されるものであり、個別に実行することはできません。

スコープによるサーバー・アフィニティー・レポートは、Tivoli CommonReporting にはインポートできません。

レポート・パッケージのインポートについて詳しくは、Tivoli Common Reportingの資料を参照してください。

手順

TADDM レポートをインポートするには、以下のステップを実行します。

1. Tivoli Common Reporting 1.3 を使用している場合は、以下のステップを実行します。


a. Tivoli Common Reporting レポート・ナビゲーション・ウィンドウで、「ナビゲーション」タブに進みます。

b. ナビゲーション・ツリーのルート・ノード (「レポート・セット」) を右クリックします。

c. 「インポート・レポート・パッケージ」をクリックします。

d. 「インポート・レポート・パッケージ」ウィンドウで、TADDMReports.zip

レポート・パッケージ・ファイルのロケーションを指定します。このファイルは、$COLLATION_HOME/etc/reporting ディレクトリーにあります。

e. 「拡張オプション」を展開し、以下を実行します。

1) 「上書き」チェック・ボックスを選択します。これにより、前にインストールされたレポートのコピーがすべて確実に上書きされます。

2) 「セキュリティー・セット」フィールドに、レポート・パッケージのコンテンツのインポート先セキュリティー・セットの名前を入力します。

f. 「インポート」をクリックします。 TADDM レポート・パッケージがTivoli Common Reporting データ・ストアにインポートされます。


a. コマンド行を開き、TIP_install_dir/tipv2Components/TCRComponent/bin

に移動します。

b. インポート・コマンドを実行します。

trcmd -user userID -password password -import -bulk pkgFile

ここで、pkgFile は TADDM サーバー上の $COLLATION_HOME/etc/reporting から Tivoli Common Reporting サーバーにコピーするTADDMReports.zip レポート・パッケージ・ファイルへのパスです。

c. TADDM レポート・パッケージが Tivoli Common Reporting データ・ストアにインポートされます。

3. Tivoli Common Reporting 3.1 を使用している場合は、次の手順を実行します。

a. コマンド行を開き、JazzSM_install_dir/reporting/bin に移動します。

b. インポート・コマンドを実行します。

trcmd -user userID -password password -import -bulk pkgFile

ここで、pkgFile は TADDM サーバー上の $COLLATION_HOME/etc/reporting から Tivoli Common Reporting サーバーにコピーするTADDMReports.zip レポート・パッケージ・ファイルへのパスです。

c. TADDM レポート・パッケージが Tivoli Common Reporting データ・ストアにインポートされます。

次のタスク

TADDM レポートをインポートした後は、各レポートの JDBC データ・ソースを再構成する必要があります。

管理 191

Tivoli Common Reporting での TADDM BIRT レポートの構成TADDM レポートを Tivoli Common Reporting にインポートした後は、各レポートが使用する JDBC データ・ソースを構成する必要があります。

始める前に

JDBC アクセスを構成する前に、適切な JDBC ドライバー・ファイルが以下のTivoli Common Reporting ドライバー・ディレクトリーにインストールされていることを確認してください。 Tivoli Common Reporting 1.3 の場合、次のディレクトリーにあります。

tcr_install_dir/products/tcr/lib/birt-runtime-2_2_1/ReportEngine/plugins/org.eclipse.birt.report.data.oda.jdbc_2.2.1.r22x_v20070919/drivers

Tivoli Common Reporting 2.1 の場合、次のディレクトリーにあります。

tip_install_dir/tip21Components/TCRComponent/lib/birt-runtime-2_2_2/ReportEngine/plugins/org.eclipse.birt.report.data.oda.jdbc_2.2.2.r22x_v20071206/drivers

Tivoli Common Reporting 3.1 の場合、次のディレクトリーにあります。

JazzSM_install_dir/reporting/lib/birt-runtime-2_2_2/ReportEngine/plugins/org.eclipse.birt.report.data.oda.jdbc_2.2.2.r22x_v20071206/drivers

Oracle データベースを使用している場合は、このディレクトリーに ojdbc14.jarまたは ojdbc5.jarが必ず含まれるようにしてください。


インポートされたレポートは、デフォルトのデータ・ソースを使用するように初期構成されています。ディスカバリー・データが保管されているデータベースを使用するように、各 TADDM レポートのデータ・ソース・プロパティーを変更する必要があります。 TADDM レポートは共用データ・ソースを使用しません。そのため、以下の手順を実行して、すべての TADDM レポートのデータ・ソース・プロパティーを構成してください。

手順

Tivoli Common Reporting の JDBC データ・ソースを構成するには、以下のステップを実行します。


a. Tivoli Common Reporting の「レポート」テーブルで、構成する TADDMレポートを右クリックします。

b. ポップアップ・メニューから「データ・ソース」を選択します。

c. 「レポートのデータ・ソース」ウィンドウで、JDBC ドライバー、URL、ユーザー ID およびパスワード情報を入力します。これらの設定に対する正しい値は、$COLLATION_HOME/etc ディレクトリー内のcollation.properties ファイルで調べることができます。

d. 上記の手順を構成する TADDM レポートごとに繰り返します。

2. Tivoli Common Reporting 2.1 または 3.1 を使用している場合は、次の手順を実行します。


a. コマンド行を開き、tip_install_dir/tip21Components/TCRComponent/bin

(Tivoli Common Reporting 2.1 の場合)、または JazzSM_install_dir/reporting/bin (Tivoli Common Reporting 3.1 の場合) に移動します。

b. すべての JDBC ソースをすべてのレポート用に構成するには、以下のように modify コマンドを 1 行で実行します。

重要: 以下のコマンドには、BIRT レポートが格納されたディレクトリーの名前である 'IBM Tivoli Products' が含まれています。この名前は、TADDM 7.3.0.1 以降に適用されます。TADDM 7.3.0 を使用する場合、この名前を 'Tivoli Products' に置き換えます。

trcmd -user userID -password password -modify-datasources -reports -reportname "/content/package[@name='IBM TivoliProducts']/folder[@name='TADDM Reports']//report" -setdatasourceodaDriverClass=driverClass odaURL=jdbcUrlodaUser=dbUser odaPassword=dbPassword

例えば、DB2 データベースを使用する場合、以下のコマンドを 1 行で入力します。

trcmd -user tipadmin -password tipadmin -modify -datasources -reports-reportname "/content/package[@name='IBM Tivoli Products']/folder[@name='TADDM Reports']//report" -setdatasourceodaDriverClass=com.ibm.db2.jcc.DB2DriverodaURL=jdbc:db2://100.101.102.103:50000/SAMPLEDBodaUser=db2inst1 odaPassword=db2inst1

例えば、Oracle データベースを使用する場合、以下のコマンドを 1 行で入力します。

trcmd -user tipadmin -password tipadmin -modify -datasources -reports-reportname "/content/package[@name='IBM Tivoli Products']/folder[@name='TADDM Reports']//report" -setdatasourceodaDriverClass=oracle.jdbc.driver.OracleDriverodaURL=jdbc:oracle:thin:@192.168.0.1:1521:orclodaUser=taddm_dev odaPassword=taddm_dev

TADDM レポートの確認TADDM レポートが Tivoli Common Reporting に正しく表示されていることを確認できます。

手順

TADDM レポートが Tivoli Common Reporting に正しく表示されていることを確認するには、以下のステップを実行します。



3. TADDM フォルダーと Tivoli 製品フォルダーが表示されていることを確認します。

4. 「TADDM」をクリックします。

5. 「実行」アイコンをクリックして、いずれかのレポートを実行します。レポートが表示されます。

6. レポートが正しく完全に表示されていることを確認します。

7. パンくずリストを使用して、「パブリック・フォルダー」に戻ります。

管理 193

8. 「Tivoli 製品」 > 「TADDM レポート」をクリックします。「実行」アイコンをクリックして、いずれかのレポートを実行します。レポートが表示されます。

9. レポートが正しく完全に表示されていることを確認します。

BIRT を使用したレポートBusiness Intelligence and Reporting Tools (BIRT) レポート作成機能を使用して、TADDM データベースからのデータに基づく事前定義レポートおよびカスタム・レポートを実行することができます。

BIRT レポートの概説データ管理ポータルで利用可能な組み込みレポートに加え、オープン・ソースのBusiness Intelligence and Reporting Tools (BIRT) システムをもとに、レポートを設計、作成、およびインストールすることもできます。

重要: データ管理ポータルの BIRT レポート・ビューアー (BIRT ランタイム・エンジン) での BIRT レポートの表示は安全ではないため、使用不可になっています。BIRT レポートは、TADDM レポートを TCR にインポートした後、TivoliCommon Reporting (TCR) を使用して表示することをお勧めします。

リスクが認識される場合は、以下の段落の説明に従い、BIRT レポート・ビューアーを復元して使用することができます。

TADDM には、オープン・ソースの BIRT ランタイム・エンジンが統合コンポーネントとして含まれています。さらに TADDM には、数百の定義済みデータベース・ビューと、定義済みレポートが含まれています。定義済みレポートに加え、BIRT デザイナー・ツールを使用して、TADDM BIRT ランタイム・エンジンとともに使用する新しいレポートを作成することもできます。これらのレポートでは、定義済みデータベース・ビューを使用してデータを抽出する JDBC データ・ソースを利用できます。

データ管理ポータル・インターフェースを使用すると、これらの BIRT レポートを管理できます。新規レポートの追加、選択したレポートのダウンロード、アップロードしたレポートの削除、レポートの実行が可能です。定義済みレポートをパッケージ化し、Tivoli Common Reporting ツールとともに使用することもできます。

Business Intelligence and Reporting Tools

Business Intelligence and Reporting Tools (BIRT) はオープン・ソースで、レポートを設計、作成、および実行するための、Eclipse ベースのシステムです。TADDM用の BIRT レポートを作成し、定義済みデータベース・ビューの JDBC データ・ソースおよび SQL 照会を使用するように設計できます。

重要: BIRT レポートでは、TADDM データベース表から直接取り込んだデータは使用しないようにしてください。その代わり、必ず JDBC データ・ソースおよびTADDM データベース・ビュー (これらについては TADDM の「SDK 開発者ガイド」に説明があります) を使用するようにレポートを設計してください。

BIRT システムには以下の 2 つの主要コンポーネントがあります。

v 新規レポートを設計および作成するグラフィック・ツール BIRT Designer


v レポートの実行および公開したレポート出力のレンダリングをサポートするBIRT ランタイム・エンジン

TADDM には BIRT ランタイム・エンジンが含まれていて、定義済みレポートの実行に使用できます。ユーザー独自の BIRT レポートを作成するときは、TADDMに含まれている BIRT ランタイム・エンジンのバージョン (現在のバージョンは2.2.1) に合った BIRT デザイナー・ツールをダウンロードする必要があります。

BIRT デザイナー・ツールのダウンロード方法など、BIRT プロジェクトについて詳しくは、http://www.eclipse.org/birtを参照してください。

関連タスク:

212 ページの『BIRT レポート・ビューアーの復元』セキュリティーに関するリスクを認識しているが、それでも BIRT レポート・ビューアーを使用する場合は、BIRT レポート・ビューアーを復元してください。

定義済み BIRT レポートTADDM に組み込まれた定義済み BIRT レポートは、ディスカバーされたシステム、オペレーティング・システム、およびサーバー・プロセスに関する情報を提供します。

アプリケーション・サーバー・インベントリー・レポート:

アプリケーション・サーバー・インベントリー・レポートには、TADDM によってディスカバーされたすべてのアプリケーション・サーバーが含まれます。このレポートを実行するときには、パラメーター値を指定して、特定タイプのアプリケーション・サーバーにレポートを制限できます。このレポートは、完全修飾ホスト名でリストしたシステムごとに、ディスカバーされたアプリケーション・サーバーをグループ化します。

このレポートのデータは、CM_APP_SERVERS_PER_HOST_V データベース・ビューから取得されます。

コンピューター・システム・インベントリー・レポート:

コンピューター・システム・インベントリー・レポートには、IP アドレスが割り当てられた TADDM データベース内のすべてのコンピューター・システムが、完全修飾ホスト名ごとにリストされます。このレポートにはパラメーターがありません。

このレポートは、スプレッドシート・アプリケーションにインポート可能な、コンマ区切りファイルにエクスポートされるように設計されています。システムに IPアドレスがない場合、そのシステムはこのレポートに含まれません。コンピューター・システム名は固有の IP アドレス (127.0.0.1 ループバック・アドレスを含む)ごとに 1 回リストされるため、同じコンピューター・システム名が複数回レポートにリストされる場合もあります。

このレポートのデータは、CM_COMPUTER_SYSTEMS_V データベース・ビューから取得されます。

管理 195

http://www.eclipse.org/birt

オペレーティング・システムのタイプによるコンピューター・システム・インベントリー・レポート:

オペレーティング・システムのタイプによるコンピューター・システム・インベントリー・レポートには、ディスカバー済みのオペレーティング・システムを持つすべてのディスカバーされたコンピューター・システムが含まれます。このレポートにはパラメーターがありません。

このレポートは、スプレッドシート・アプリケーションにインポート可能な、コンマ区切りファイルにエクスポートされるように設計されています。コンピューター・システム名は固有の IP アドレス (127.0.0.1 ループバック・アドレスを含む)ごとに 1 回リストされるため、同じコンピューター・システム名が複数回レポートにリストされる場合もあります。このレポートに組み込まれるためには、オペレーティング・システムが TADDM データベース内のシステムに関連付けられていなければなりません。同様に、TADDM データベースでオペレーティング・システムが定義されていないシステムは含まれません。

レポート内のシステム名をクリックすると、そのシステムのインベントリーの詳細レポートが開きます。

このレポートのデータは、以下のデータベース・ビューから取得されます。v DP_UNITARY_COMP_GENERAL_Vv DP_UNITARY_COMP_OS_Vv DP_UNITARY_COMP_IP_INTERFACE_Vv BB_OPERATINGSYSTEM62_V

ITNM IP レポート:

Network Manager 製品のインストール済みインスタンスに関する情報を提供し、1つのコンピューター・システムに関係のあるすべての Network Manager リソースのリストを示します。

Network Manager インベントリー・レポートは、TADDM ドメイン・マネージャー・コンソールで使用可能です。このレポートには以下のセクションがあります。

サーバーの要約Network Manager 製品のインストール済みインスタンスに関する情報を提供します。これには、インストール済みの Network Manager のバージョン、Network Manager がインストールされているサーバーのホスト・アドレス、および Network Manager GUI にアクセスするための URL などが含まれます。

リソースの要約1 つのコンピューター・システムに関係のあるすべての Network Managerリソースのリストを示します。これには、IP アドレス、製造元、リソースのタイプ (例えば、ルーター)、および Network Manager データベースでの固有の ID などが含まれます。

簡潔なコンピューター・システム・インベントリー・レポート:

簡潔なコンピューター・システム・インベントリー・レポートにより、レベル 1 ディスカバリー・プロファイルを使用してディスカバーされた IP アドレスを表示す


ることができます。各 IP アドレスごとに、レポートには、関連するコンピューター・システム名、およびオペレーティング・システム名または制御ソフトウェア名も表示されます (この情報がディスカバーされた場合)。

簡潔なコンピューター・システム・インベントリー・レポートは、レベル 1 のディスカバリーの後に使用されることを意図していますが、レベル 3 のディスカバリーの後に使用することもできます。ただし、資格情報を使用したディスカバリーの後の場合は、コンピューター・システム・インベントリー・レポートなどその他のレポートの方が、より詳細な情報が提供されます。

ファイバー・チャネル・ネットワーク・レポート:

ファイバー・チャネル・ネットワーク・レポートには、選択されているファイバー・チャネル・スイッチとその他のコンピューター・システムの間のファイバー・チャネル接続が表示されます。

このレポートを実行するには、ファイバー・チャネル・スイッチの World WideName (WWN) を指定して、スイッチとその他のコンピューター・システムの間のファイバー・チャネル接続を表示します。「パラメーター」ウィンドウで、名前(WWN) を入力するか、またはディスカバーされたファイバー・チャネル・スイッチのドロップダウン・リストから名前を選択します。

以下の情報が、接続された各コンピューター・システムにレポートとして表示されます。

v コンピューター・システム (表示名。ファイバー・チャネル・スイッチの場合はWWN)

v 製造元

v モデル

v シリアル番号

レポートでコンピューター・システムの表示名をクリックすると、別のファイバー・チャネル・ネットワーク・レポートが開きます。このレポートには、選択されたコンピューター・システムと他のコンピューター・システム間のファイバー・チャネル接続が表示されます。

ホスト・バス・アダプター・インベントリー・レポート:

ホスト・バス・アダプター・インベントリー・レポートには、ディスカバーされたすべてのホスト・バス・アダプターと、これらのアダプターが取り付けられているコンピューター・システムのリストが表示されます。

ディスカバーされた各ホスト・バス・アダプターについて、以下の情報がレポートに表示されます。

ホスト・バス・アダプター名ホスト・バス・アダプターの名前。

完全修飾ドメイン名ホスト・バス・アダプターが取り付けられているコンピューター・システムの完全修飾ドメイン名。

管理 197

ホストはストレージ・アレイを使用するホスト・コンピューター・システムが、ストレージ・アレイ内のストレージ・ボリュームを使用するかどうかを示すブール値。

インベントリーの要約:

インベントリーの要約レポートには、TADDM によってディスカバーされたスコープに基づき、ディスカバーされたコンピューター・システムにインストールされているオペレーティング・システムの円グラフが含まれます。円の各セグメントはオペレーティング・システムのタイプを表し、そのオペレーティング・システムでディスカバーされた実行中サーバーの総数を示します。このレポートにはパラメーターがありません。

円の任意のセグメントをクリックすると、選択されたオペレーティング・システム・タイプの詳細なコンピューター・システム・インベントリー・レポートが開きます。

このレポートのデータは、BB_OPERATINGSYSTEM62_V データベース・ビューから取得されます。

モニター範囲レポート:

モニター範囲レポートは、ご使用の環境内のさまざまなコンポーネントの詳細を表示します。ご使用の環境に含まれるオペレーティング・システム、データベース、Microsoft アプリケーション、VMware サーバー、および System p コンポーネントに関するレポートを生成することができます。これらのコンポーネントは、IBMTivoli Monitoring 6.1 以降のエージェントによってモニターされます。データ管理ポータルの「BIRT レポート」ペインからこのレポートを実行できます。

199 ページの表 37 は、使用可能な範囲レポートを示しています。オペレーティング・システムのレポート・モニター範囲には、IBM® Tivoli® Monitoring スコープ・センサーによってデータを取り込むことができます。ただし、残りのレポートでは、IBM® Tivoli® Monitoring ディスカバリー・ライブラリー・アダプター(DLA) がレポートにデータを取り込む必要があります。

レポートには次の 3 つのセクションがあります。

タイプ別の範囲

このセクションには、モニター対象インスタンス数、モニター対象外のインスタンス数、および合計インスタンス数がレポート・タイプごとにグループ化されて表示されます。「範囲の詳細」ウィンドウには、以下の統計のグラフィカル表現が表示されます。

v 全体の範囲

v プラットフォームが対象とする範囲

範囲の詳細

このセクションには、完全修飾ドメイン名、管理対象システム名、およびモニター状況がレポート・タイプごとにグループ化されて表示されます。モニター状況は、モニター対象のエージェントがある場合にはそのエージェントのバージョン情報と共にリストされます。モニター対象システムの MSNをクリックすると、「エージェントの詳細」ウィンドウが開きます。


エージェントの詳細

このセクションには、エージェントと、エージェントで稼働しているオペレーティング・システムの詳細情報が表示されます。表示される情報は、エージェントがモニター対象であるかどうかによって異なります。 IBMTivoli Monitoring の「Tivoli Enterprise Portal」ビューへのコンテキスト起動リンクと共に、アフィニティーおよびソース・トークン情報が含まれています。

「管理ソフトウェア・システム」セクションには、インストールされている IBMTivoli Monitoring エージェントのインベントリーと、IBM Tivoli Monitoring のワークスペースへのコンテキスト起動リンクが表示されます。「モニター範囲要約」にはモニター対象システムおよびモニター対象外システムのリストが表示されます。モニター・エージェントをモニターおよび保守する際に、このリストを使用できます。

レベル 1 のディスカバリーは、IBM Tivoli Monitoring スコープ・センサーを使用して、オペレーティング・システム・レポートのモニター範囲にデータを取り込むことができます。他のレポートには、IBM Tivoli Monitoring ディスカバリー・ライブラリー・アダプター (DLA) によってデータを取り込む必要があります。 IBMTivoli Monitoring DLA については、TADDM の「管理者ガイド」を参照してください。

表 37 は、使用可能な範囲レポートを示しています。

表 37. モニター範囲レポート

レポート名説明

オペレーティング・システムのモニター範囲

このレポートは、ご使用の環境内のオペレーティング・システムの詳細を表示します。

データベースのモニター範囲このレポートは、ご使用の環境内の DB2 インスタンスおよび SQL サーバーの詳細を表示します。

Microsoft アプリケーションのモニター範囲

このレポートは、Active Directory、ClusterServer、Exchange Server、ホスト・インテグレーション・サーバー (Hyper-V サーバー役割が有効)、InternetInformation Services サーバーの詳細を表示します。

VMware のモニター範囲このレポートは、VMware ESX サーバーおよび VMware 仮想センター・サーバーの詳細を表示します。

System p のモニター範囲このレポートは、System p、Hardware ManagementConsole、仮想入出力サーバー、および AIX 論理区画の詳細を表示します。

センサー・レポート:

定義済みセンサー・レポートでは、センサー・メトリックで収集された情報が照合されます。

200 ページの表 38 は、使用可能な定義済みセンサー・レポートを示しています。

管理 199

表 38. 定義済みセンサー・レポート


TADDM_SENSORS_WEEKLY_METRICS_ALL

TADDM_SENSORS_WEEKLY_METRICS

このレポートは、レベル 1 ディスカバリー・プロファイル、レベル2 ディスカバリー・プロファイル、またはレベル 3 ディスカバリー・プロファイルで有効に設定されているセンサーの週次成功率(%) を示します。以下の情報が表示されます。

v 日付

v レベル 1 (L1) 成功率 (%)



v L1、L2 成功率 (%)

v すべてが成功した率 (%)

2 番目の「TADDM_SENSORS_WEEKLY_METRICS」レポートには同じ情報が含まれていますが、棒グラフを使用して情報が表示されます。

TADDM_SENSORS_SUMMARY_TOTAL

TADDM_SENSORS_SUMMARY

このレポートには実行されて正常に完了したセンサーの総数が表示されます。以下の情報が表示されます。

v レベル

v CI が保管された実行

v 成功数

v 失敗数

また、ディスカバリー・プロファイル・レベルと各レベルでの全体的な成功率と失敗率を示す要約が表示されます。

「TADDM_SENSORS_SUMMARY」レポートには、ディスカバリー中の個々のセンサーの成功率 (%) と失敗率 (%) が示されます。以下の情報が表示されます。

v レベル

v センサー

v 実行数

v 成功数

v 失敗数

v 成功率 (%)

v 失敗率 (%)

TADDM_SENSORS_SERVER_SCANS_IP このレポートは、IP アドレスを指定してサーバーのスキャンを実行した後の状況を示します。以下の情報が表示されます。

v 週

v 状況

レポートの先頭に、IP アドレス、ホスト名、完全修飾ドメイン名、初回スキャン実行日と状況、最終スキャン実行日と状況の要約情報が示されます。


表 38. 定義済みセンサー・レポート (続き)


TADDM_SENSORS_SERVER_SCANS_HOSTNAME

このレポートは、ホスト名を指定してサーバーのスキャンを実行した後の状況を示します。以下の情報が表示されます。

v 週

v 状況

レポートの先頭に、ホスト名、IP アドレス、完全修飾ドメイン名、初回スキャン実行日と状況、最終スキャン実行日と状況の要約情報が示されます。

TADDM_SENSORS_MONTHLY_COVERAGE このレポートは、セッション・センサーの月次範囲を示す棒グラフを示します。スキャン実行回数、成功したスキャンの数、および失敗したスキャンの数に関する情報が含まれます。セッション・センサーにより、TADDM サーバーとターゲット・コンピューター・システム間でセッションが作成されます。

TADDM_SENSORS_METRICS_LEVEL_1_AND_2

TADDM_SENSORS METRICS_LEVEL3

このレポートは、指定された週におけるレベル 1 およびレベル 2ディスカバリーの実行時の個々のセンサーの成功率 (%) を示す棒グラフを示します。

「TADDM_SENSORS METRICS_LEVEL3」レポートの棒グラフは、レベル 3 ディスカバリー実行時の個々のセンサーのメトリックを示します。

TADDM_SENSORS_FAILED_LEVELS_1_2_3

TADDM_SENSORS_FAILED_LEVEL

このレポートは、指定された週におけるレベル 1、レベル 2、またはレベル 3 ディスカバリーの実行時の失敗に基づく円グラフを示します。グラフの各セグメントは、セッションの問題、センサーの問題、接続の問題、およびその他の問題を示します。

「TADDM_SENSORS_FAILED_LEVEL」レポートの円グラフは、指定されたディスカバリー・レベルのメトリックを示します。

TADDM_SENSORS_EVENTS_SENSOR_IP

TADDM_SENSORS_EVENTS_SENSOR

TADDM_SENSORS_EVENTS_IP

TADDM_SENSORS_DONE_EVENTS_RUN

このレポートは、指定されたセンサーおよび IP アドレスのイベント・データを示します。以下の情報が表示されます。

v 日付

v センサー詳細

v 重大度

v 説明

「TADDM_SENSORS_EVENTS_SENSOR」レポートには同じ情報が含まれていますが、このレポートでは指定されたセンサーのイベント・データが表示されます。

「TADDM_SENSORS_EVENTS_IP」レポートには同じ情報が含まれていますが、このレポートでは指定された IP アドレスのイベント・データが表示されます。

「TADDM_SENSORS_DONE_EVENTS_RUN」レポートには同じ情報が含まれていますが、指定されたディスカバリー実行のイベント・データが表示されます。

管理 201

スコープによるサーバー・アフィニティー:

スコープによるサーバー・アフィニティー・レポートは、サーバー間の関係を、それぞれの関係のソースおよびターゲットに基づいた配置で表示します。最初の表では、指定されたスコープ内にある、関係のソースであるすべてのサーバーと、それらのサーバーから他のサーバーへの接続が示されます。 2 番目の表では、指定されたスコープ内にある、関係のターゲットであるすべてのサーバーと、他のサーバーからそれらのサーバーへの接続が示されます。

スコープによるサーバー・アフィニティー・レポートは、ドメイン・サーバー・デプロイメントでのみ使用可能です。

サーバー間通信を視覚化しているグラフを表示するには、「アフィニティー・グラフを起動する」をクリックします。このグラフには、コンピューター・システム間のトランザクションおよびサービスの依存関係が表示されます。依存関係は、システム間に描かれたリンクによって示されます。グラフには、ディスカバリー・スコープ内の少なくとも 1 つのシステムを含むすべての依存関係のリンクが含まれ、そのスコープのメンバーであるシステムが黄色で強調表示されます。

アフィニティー・グラフに表示されるリンクは、トランザクションまたはサービスのいずれかの関係を表すことができます。リンクの方向によって、依存関係においてどちらのシステムがソースで、どちらのシステムがターゲットとなるのかが表されます。ソース・オブジェクトとターゲット・オブジェクトは、以下のように、関係に応じていくつかのタイプになり得ます。

v コンピューター・システム

v アプリケーション・サーバー

v サービス

グラフ上のリンクは、常にコンピューター・システム間に描かれます。アプリケーション・サーバーまたはサービスを含む関係の場合、リンクはホスト・コンピューター・システムにつながります。依存関係に関する詳細 (ソース、ターゲット、コマンド名、および関連するポート番号など) を確認するには、図のリンク上にマウス・ポインターを移動してください。

スコープによるサーバー・アフィニティー・レポートは、Tivoli CommonReporting にはインポートできません。

スナップショット・レポート:

定義済みスナップショット・レポートでは、1 つ以上のスナップショットによって取得された情報を照合します。

スナップショットとは、ディスカバーされたコンピューターの情報の特定の時点におけるコピーです。スナップショットの作成について詳しくは、 213 ページの『スナップショット・ツールの使用』を参照してください。

具体的なレポート名は、BIRT レポートを実行および表示するサーバーによって異なります。ドメイン・サーバーまたはストレージ・サーバーでデータ管理ポータルを使用している場合は、標準レポート (TADDM_SNAPSHOT_CHANGE など) を実行します。同期サーバーでデータ管理ポータルを使用している場合は、名前に


「SYNC」が含まれているレポート (TADDM_SNAPSHOT_SYNC_CHANGE など)を実行します。次に示すレポートは例外であり、すべてのサーバーで同じ名前です。

v TADDM_SNAPSHOT_FRAME

v TADDM_SNAPSHOT_HOST

BIRT レポートを Tivoli Common Reporting にインポートすると、変更されたレポート名が表示されます。例えば、TADDM_SNAPSHOT_SYNC_SESSION_FAILED レポートが「TADDM: Detailsabout failed sessions (Enterprise)」として表示されます。

表 39 は、使用可能な定義済みスナップショット・レポートを示しています。

表 39. 定義済みスナップショット・レポート


TADDM_SNAPSHOT_FRAME ディスカバーされたサーバーに関する以下の詳細情報を表示します。

v フレーム名


v manufacturer

v model

v CPU タイプ

v CPU 速度

v CPU の数

v メモリー

v ロケーション

v サポート・エリア

v 最終ディスカバー

TADDM_SNAPSHOT_HOST 物理サーバーおよび仮想サーバーに関する以下の詳細情報を表示します。

v フレーム名

v システム名

v IP アドレス

v OS タイプ

v ホスト・タイプ

v 管理対象システム名

v 最終ディスカバー

TADDM_SNAPSHOT_SESSION_FAILED

TADDM_SNAPSHOT_SYNC_SESSION_FAILED

セッションが失敗したために、TADDM によって L2 情報を取得できなかったディスカバー対象のサーバーに関する名前および IP アドレス情報を表示します。

管理 203

表 39. 定義済みスナップショット・レポート (続き)


TADDM_SNAPSHOT_CHANGE

TADDM_SNAPSHOT_SYNC_CHANGE

異なる時刻に取られた 2 つのスナップショットを比較します。 2 つのスナップショットが取られた間の時間に追加または除去されたサーバーごとに、以下の情報が表示されます。

v name

v IP アドレス

v 仮想

また、2 つのスナップショットが取られた間の時間の、物理サーバーと仮想サーバーの比率の変化に関する情報も表示されます。

TADDM_SNAPSHOT_DISCOVERY_ERROR

TADDM_SNAPSHOT_SYNC_DISCOVERY_ERROR

ディスカバリー中に生成されたエラーに関する情報が表示されます。

TADDM_SNAPSHOT_FQDN_OS_CHANGES

TADDM_SNAPSHOT_SYNC_FQDN_OS_CHANGES

2 つのスナップショットが取られた間の時間に完全修飾ドメイン名 (FQDN)、またはオペレーティング・システム情報が変更された、サーバーに関する情報を表示します。

TADDM_SNAPSHOT_REFERENCE

TADDM_SNAPSHOT_SYNC_REFERENCE

スナップショットと参照リストを比較します。これは、参照リストにあってスナップショットにはないサーバーに関する情報、およびスナップショットにあって参照リストにはないサーバーに関する情報を表示します。

TADDM_SNAPSHOT_RECONCILIATION_SUMMARY

TADDM_SNAPSHOT_SYNC_RECONCILIATION_SUMMARY

スナップショットを取るようにプロンプトを出し、ディスカバーされたサーバーに関する以下の要約情報を表示します。

v ベースライン・ホスト名

v ベースライン IP アドレス

v TADDM ホスト名

v TADDM IP アドレス

v ステータス

v エラー理由


表 39. 定義済みスナップショット・レポート (続き)


TADDM_SNAPSHOT_RECONCILIATION_DETAIL

TADDM_SNAPSHOT_SYNC_RECONCILIATION_DETAIL

スナップショットを取るようにプロンプトを出し、ディスカバーされたサーバーに関する以下の詳細情報を表示します。

v ベースライン・ホスト名

v ベースライン IP アドレス



v ステータス

v エラー理由

v エラーの説明

v スコープ名

v フィルターにかけられた除外

v TADDM フレーム


v TADDM FQDN

v TADDM 名

v TADDM DisplayName

v TADDM JdoClass

v TADDM OsDerived

v TADDM OsName


v TADDM シリアル番号

v TADDM 製造元

v TADDM モデル

v TADDM ホスト・タイプ

v TADDM 仮想

v TADDM タイプ

v TADDM ディスカバリー日

ホスト別のストレージ・アレイ・レポート:

ホスト別のストレージ・アレイ・レポートには、指定されたコンピューター・システムによって使用されているストレージ・ボリュームとストレージ・アレイのリストが表示されます。

このレポートを実行すると、ストレージ情報を表示するコンピューター・システムのホスト名の入力を求めるプロンプトが出されます。「パラメーター」ウィンドウで、ホスト名を入力するか、またはドロップダウン・リストから選択します。

以下の情報がレポートに表示されます。

v ストレージ・ボリューム

v ストレージ・アレイ

管理 205

v 製造元

v モデル


v 使用可能な容量

v 割り振られた容量

ストレージ・アレイ利用者レポート:

ストレージ・アレイ利用者レポートには、指定されたストレージ・アレイを使用するコンピューター・システムとアプリケーション・サーバーのリストが表示されます。

このレポートを実行すると、ストレージ・アレイの名前の入力を求めるプロンプトが出されます。「パラメーター」ウィンドウで、ストレージ・アレイ名を入力するか、またはドロップダウン・リストから選択します。

レポートは以下の 3 つの表の形式で表示されます。

ストレージ・アレイ storage_array_name を使用するコンピューター・システムこのテーブルには、指定されたストレージ・アレイを使用するディスカバー済みコンピューター・システムがすべてリストされます。

ストレージ・アレイ storage_array_name を使用するアプリケーション・サーバーこのテーブルには、指定されたストレージ・アレイを使用するディスカバー済みアプリケーション・サーバーがすべてリストされます。

ストレージ・アレイ storage_array_name を使用するビジネス・アプリケーションこのテーブルには、指定されたストレージ・アレイを使用するディスカバー済みビジネス・アプリケーションがすべてリストされます。

システム接続トポロジー・レポート:

システム接続トポロジー・レポートには、他のコンピューター・システムとネットワーク接続されたコンピューター・システムのテキスト・レポートが示されます。レポートを実行するときには、レポートの実行対象となる構成アイテムを入力し、それがコンピューター・システムまたはビジネス・アプリケーションのどちらであるのかを指定する必要があります。

レポートがコンピューター・システムに関して実行される場合、選択したコンピューター・システムとネットワーク接続されたすべてのコンピューター・システムが、各ネットワーク接続用のメトリックとともに表に表示されます。レポートがビジネス・アプリケーションに関して実行される場合、選択したビジネス・アプリケーションとネットワーク接続されたすべてのコンピューター・システムが、表に表示されます。

レポート内のコンピューター・システム名をクリックして、コンピューター・システムごとに、システム接続トポロジーを表示することができます。

システム使用率 (毎時) ピーク・レポート:

システム使用率 (毎時) ピーク・レポートには、特定日における、特定のスコープ内のシステムに関するシステム使用率 (毎時) ピーク値が表示されます。


使用率メトリックには、以下の情報が含まれます。

v 毎時 95 パーセント CPU 使用率

v 毎時ピーク・パーセント・メモリー使用率

v 毎時ピーク・ネットワーク帯域幅使用率

v 毎時ピーク・ディスク I/O 使用率

システム使用率レポート:

システム使用率レポートには、汎用サーバー・オペレーティング・システム構成と、関連する使用率情報が表示されます。

サーバー・オペレーティング・システム構成データには、以下の情報が含まれます。

v CPU

v メモリー

v ファイル・システム

これは、TADDM で取得できる、最新のサーバー構成情報です。サーバー使用率データには、以下が含まれます。

v CPU

v メモリー

v ネットワーク

v ディスク

不明サーバー・レポート:

不明サーバー・レポートには、TADDM で認識されないすべてのディスカバーされたサーバー・プロセスが含まれます。このレポートは、完全修飾ホスト名でリストしたシステムごとに、ディスカバーされたサーバー・プロセスをグループ化します。このレポートにはパラメーターがありません。

トポロジー・ビルド・エージェントによるディスカバリーの実行後に、不明サーバーが識別されます。トポロジー・ビルド・エージェントは、設定されている頻度値に基づいて定期的にバックグラウンドで実行されます。このため、ディスカバリー完了直後には不明サーバーが認識されないことがあります。トポロジー・ビルド・エージェントのデフォルトの実行頻度は 4 時間ごとです。

このため、トポロジー・ビルド・エージェントの完了前に不明サーバー・レポートを実行すると、レポートに不明サーバーが一部リストされないことがあります。

以下の情報がレポートに表示されます。

名前不明サーバー・プロセスが実行されているコンピューターの名前。

コンテキスト IP不明なサーバー・プロセスを実行しているコンピューターの IP アドレス

PID 不明サーバー・プロセスのプロセス ID。

PPID 不明サーバー・プロセスの親プロセスのプロセス ID。

管理 207

コマンド行不明サーバー・プロセスを実行するために使用されるコマンド。

このレポートのデータは、BB_RUNTIMEPROCESS15_V データベース・ビューから取得されます。

BIRT レポートの実行データ管理ポータルの「分析性」セクションを使用して、BIRT レポートを実行できます。


重要: データ管理ポータルで BIRT レポートを実行できるのは、BIRT レポート・ビューアーを有効にした場合に限られます。 BIRT レポート・ビューアーは、セキュリティーの問題のために無効になっています。 BIRT レポートを表示する代わりの方法として、TADDM レポートを TCR にインポートした後に Tivoli CommonReporting (TCR) を使用する方法があります。リスクを認識している場合は、BIRTレポート・ビューアーを復元してもかまいません。

手順

BIRT レポートを実行するには、以下のステップを実行します。

1. 「機能」ペインで、「分析性」をクリックします。

2. 「分析性」セクションで、「BIRT レポート」をクリックします。「TADDMBIRT レポート」リストが開き、使用可能なすべての BIRT レポートが表示されます。

3. 「TADDM BIRT レポート」リストで、実行するレポートをクリックして強調表示します。

4. オプション: ロケーション・タグ値を指定します。 COLLATION_HOME/etc/collation.propertes ファイルの com.ibm.cdb.locationTaggingEnabled 値をtrue に設定する必要があります。この特定のロケーション・タグのレポート・データのみが表示されます。

注: TADDM に含まれる BIRT レポートは現時点では、追加カスタマイズのないロケーション・フィルタリングをサポートしていません。

5. 「レポートの実行」をクリックします。レポートにパラメーターがある場合、パラメーター値を指定するよう求めるプロンプトが出されます。パラメーター値の入力が完了したら、「OK」をクリックします。

タスクの結果

「BIRT レポート・ビューアー」ウィンドウに、定様式レポートが表示されます。レポートの上部にあるアイコンをクリックしてレポートを前後にページ送りするか、レポートを印刷するか、またはファイルにエクスポートします。レポート・データのサブセットに関する追加の詳細を表示する詳細レポートを開くには、レポート内のリンクをクリックします。

注: .doc 形式でエクスポートされたレポートは、Microsoft Word 2003 およびそれ以降と互換性を持ちます。


コマンド行インターフェースからの BIRT レポートの実行TADDM サーバーのコマンド行インターフェースから BIRT レポートを実行できます。

手順

コマンド行インターフェースから BIRT レポートを実行するには、以下のステップを実行します。

1. コマンド・プロンプトを開き、ご使用の TADDM のバージョンに応じて、以下のいずれかのディレクトリーにナビゲートします。

v 7.3.0: $COLLATION_HOME/deploy-tomcat/birt-viewer/WEB-INF/resources

v 7.3.0.1 以降: $COLLATION_HOME/apps/birt-viewer/WEB-INF/resources

2. BIRT_HOME 変数を設定します。以下のいずれかを実行します。

v Linux では、ご使用の TADDM のバージョンに応じて、以下のいずれかのコマンドを実行します。

– 7.3.0:

export BIRT_HOME=$COLLATION_HOME/deploy-tomcat/birt-viewer

– 7.3.0.1 以降:

export BIRT_HOME=$COLLATION_HOME/apps/birt-viewer

v Windows では、ご使用の TADDM のバージョンに応じて、以下のいずれかのコマンドを実行します。

– 7.3.0:

set BIRT_HOME=%COLLATION_HOME%/deploy-tomcat/birt-viewer

– 7.3.0.1 以降:

set BIRT_HOME=%COLLATION_HOME%/apps/birt-viewer

3. BIRT レポートを実行します。以下のいずれかを行います。

v Linux では、以下のコマンドを実行します。

./genReport.sh -f format -o output -F parameters report

v Windows では、以下のコマンドを実行します。

genReport.bat -f format -o output -F parameters report

genReport プログラムで使用されるコマンド行オプションを以下に示します。

formatレポート・ファイルの出力フォーマット。有効な値は PDF およびHTML です。

output出力するレポート・ファイルへのパス。例えば、/home/cognos/

utilization.pdf (Linux)、C:¥data¥utilization.pdf (Windows) などです。

parameters

(オプション) プロパティー・ファイルのパス。各プロパティーは、レポートに必要なパラメーターを示します。例えば、/home/cognos/

utilization.properties (Linux)、C:¥data¥utilization.properties

(Windows) などです。

管理 209

プロパティー・ファイルの内容の例を以下に示します。

scope=All Windows Machinesmetric=ALLoperator=N/Avalue1=N/Avalue2=N/Aappdeps=N/A

パラメーター名の中のスペースが、バックスラッシュ文字でエスケープされていることを確認してください。例えば、パラメーター名がSnapshot ID Parameter の場合、プロパティー・ファイルの項目は次のようになります。

Snapshot¥ ID¥ Parameter=my_id

report 実行するレポートのパス。レポート名にストリング「compiled」が追加されています。例えば、以下のとおりです。

v Linux および TADDM 7.3.0: $COLLATION_HOME/deploy-tomcat/

birt-viewer/WEB-INF/report/

taddm_server_utilization.rptdesigncompiled

v Linux および TADDM 7.3.0.1 以降: $COLLATION_HOME/apps/birt-

viewer/WEB-INF/report/

taddm_server_utilization.rptdesigncompiled

v Windows および TADDM 7.3.0: %COLLATION_HOME%¥deploy-

tomcat¥birt-viewer¥WEB-

INF¥report¥taddm_server_utilization.rptdesigncompiled

v Windows および TADDM 7.3.0.1 以降: %COLLATION_HOME

%¥apps¥birt-viewer¥WEB-

INF¥report¥taddm_server_utilization.rptdesigncompiled

タスクの結果

注: genReport コマンドはドリルスルー・レポートを生成しません。したがって、生成されるレポート内のリンクは機能しません。

BIRT レポートのインポートデータ管理ポータルを使用して、BIRT レポート設計をインポートすることによってカスタム・レポートを追加できます。

始める前に

カスタム・レポートを追加するには、まず、BIRT Designer ツールを使用してレポートを設計および開発する必要があります。レポート設計は、クライアント・システムからアクセス可能な .rptdesign ファイルに保管する必要があります。

注: Fix Pack 3 TADDM 7.3.0.3 以降では、拡張属性データベース・ビュー内の列には、VARCHAR などの特定のデータ・タイプが含まれています。以前の TADDMリリースでは、列には、CLOB タイプのみが含まれていました。そのため、フィックスパック 3 にアップグレードした後で、拡張属性を使用する BIRT レポートが機


能しなくなる可能性があります。例えば、拡張属性列が VARCHAR などの特定のデータ・タイプにキャストされない場合は、エラーが生成される可能性があります。

手順

BIRT レポートをインポートするには、以下のステップを実行します。

1. データ管理ポータルの「機能」ペインで、「分析性」をクリックします。

2. 「分析性」セクションで、「BIRT レポート」をクリックします。「TADDM BIRT レポート」リストが開き、使用可能なすべての BIRT レポートが表示されます。

3. 「新規」をクリックします。

4. プロンプトが出されたら、レポートの名前と説明、およびレポート設計ファイルのロケーションなど、新規レポートの詳細を指定します。名前と説明は、「TADDM BIRT レポート」リストでこのレポートを識別するために使用されます。

5. 「OK」をクリックします。

タスクの結果

レポート設計がサーバーにアップロードされ、新規レポートがデータ管理ポータルで使用できるようになります。

注: レポートがすでにサーバー上にある場合は、インポートは失敗します。これは、既存のレポートがデータ管理ポータルに表示されていない場合でも、生じることがあります。 (例えば、サーバー・アフィニティー・レポートは同期サーバーでサポートされていないため、サーバーにそのレポートが存在していても、データ管理ポータルには表示されません。)

BIRT レポートの削除データ管理ポータルを使用して、サーバーから BIRT レポートを削除できます。

始める前に

サーバーからレポートを削除すると、そのレポートによって使用されている.rptdesign ファイルがサーバーのレポート・ディレクトリーから除去されます。将来の使用に備えてレポート設計を保管したい場合には、レポートを削除する前に必ず、.rptdesign ファイルのバックアップ・コピーをとっておいてください。

手順

BIRT レポートを削除するには、以下のステップを実行します。



3. 削除するレポートを選択します。

4. 「削除」をクリックします。

管理 211

5. 「TADDM BIRT レポート」リストを最新表示するには、「最新表示」をクリックします。

タスクの結果

選択したレポートがサーバーから削除され、データ管理ポータルの「TADDMBIRT レポート」リストに表示されなくなります。さらに、このレポートの.rptdesign ファイルが TADDM サーバーのレポート・ディレクトリーから削除されます。

BIRT レポート設計のエクスポートデータ管理ポータルを使用して、サーバーから BIRT レポート設計をエクスポートできます。


既存のレポートを新しいカスタム・レポートのベースとして使用する場合、またはレポート設計を別のサーバーにインポートする場合に、レポート設計をエクスポートできます。

手順

BIRT レポート設計をエクスポートするには、以下のステップを実行します。



3. エクスポートするレポートを選択します。

4. 「ダウンロード」をクリックします。

5. ブラウザーがプロンプトを出したら、ファイルを保管することを指定し、ロケーションを指定します。

タスクの結果

選択したレポートで使用する設計が、指定したロケーションに .rptdesign ファイルとして保管されます。このファイルを開いて変更するには、BIRT Designer ツールを使用します。

BIRT レポート・ビューアーの復元セキュリティーに関するリスクを認識しているが、それでも BIRT レポート・ビューアーを使用する場合は、BIRT レポート・ビューアーを復元してください。

手順

1. collation.properties ファイルで、com.ibm.taddm.birtviewer.enabled プロパティーに true を設定します。

com.ibm.taddm.birtviewer.enabled=true



注: TADDM サーバーをアップグレードする場合、このフラグは、デフォルトで false に設定されます。

スナップショット・ツールの使用スナップショット・ツールを使用して、コンピューター・システム情報、ディスカバリー・イベント、およびスナップショット時に実行されているサーバー・アプリケーションのコピーを取得できます。

また、スナップショット・ツールを使用して、調整処理に使用される情報をロードできます。例えば次のようなことができます。

v 予想されるサーバーのリスト (参照リスト) をロードします

v 除外されるサーバーのリストをロードします

レポートを使用して、スナップショット・ツールが取り込んだ情報を照会できます。例えば次のようなものがあります。

v 追加または除去されたサーバー

v 仮想サーバーに対する物理サーバーの比率

v SSH セッションが正常に確立されなかったために、完全にディスカバーされなかったサーバー

v ディスカバーされたサーバーのリストと予想されたサーバーのリストの間の差分

制約事項: ディスカバリー・エージェントおよびトポロジー・エージェントの実行が完了した後で、スナップショットを取ってください。トポロジー・エージェントがディスカバー済み情報の処理を完了する前にスナップショットを取ると、一部のスナップショット・レポート (スナップショット・セッション失敗レポートなど) が不完全なものになる場合があります。

snapshot.sh コマンド構文:

snapshot.sh コマンドを使用して、システム、および関連するイベントとサーバーのスナップショットを取ることができます。 snapshot.sh コマンドは$COLLATION_HOME/bin ディレクトリーにあります。

TADDM サーバーで snapshot.sh コマンドを実行します。ストリーミング・サーバー・デプロイメントでは、1 次ストレージ・サーバーで snapshot.sh コマンドを実行する必要があります。

コマンド構文

snapshot.sh action [action_parameter]

パラメーター

addexclude filename [exclude_list]

除外リストをファイルに追加するか、そのリストの既存インスタンスをファイルに戻します。

addref filename [reference_list]

参照リストをファイルに追加するか、そのリストの既存インスタンスをファイルに戻します。

管理 213

clearすべてのスナップショット・データをクリアし、テーブルを除去します。

compare [snapshot_A snapshot_B]

ホスト名に基づいて、最後に取った 2 つのスナップショット (ここでは、snapshot_A および snapshot_B) の間の差分を表示します。

compareref [snapshot_A reference_list]

スナップショットと参照リストの間の差分を表示します。

comparesig [snapshot_A snapshot_B]

ホスト名またはオペレーティング・システムにおける変更に関するシグニチャーに基づいて、最後に取った 2 つのスナップショット (ここでは、snapshot_Aおよび snapshot_B) の間の差分を表示します。

compsysコンピューター・システムを表示します。

detail [snapshot_A]

最新のスナップショット (ここでは snapshot_A) におけるコンピューター・システムの詳細をすべて表示します。

detailos [snapshot_A]

最新のスナップショット (ここでは snapshot_A) におけるコンピューター・システムのオペレーティング・システム情報を表示します。

helpsnapshot.api コマンドの使用法に関する詳細なヘルプを表示します。

list [snapshot_A]

最新のスナップショット (ここでは snapshot_A) を表示します。

listall [default]

すべてのスナップショットを表示します。

listexclude [exclude_list]

最新の除外リスト、または名前で指定された除外リストを表示します。

listref [reference_list]

最新の参照リスト、または名前で指定された参照リストを表示します。

listallexcludeすべての除外リストを表示します。

listallrefすべての参照リストを表示します。

nosession [snapshot_A]

最新のスナップショット (ここでは snapshot_A) でセッションをホストできなかったコンピューター・システムを表示します。

remove snapshot_A [type]

snapshot A を除去するか、指定したタイプのすべてのスナップショットを除去します。

removeexclude exclude_list

名前で指定された除外リストを除去します。


removeref reference_list

名前で指定された参照リストを除去します。

session [snapshot_A]

最新のスナップショット (ここでは snapshot_A) でセッションをホストしたコンピューター・システムを表示します。

sensorerror [snapshot_A]

最新のスナップショット (ここでは snapshot_A) から生じたすべてのセンサー・エラーを表示します。

take [type] [desciption]

指定された場合はタイプおよび説明の情報を組み込んで、スナップショットを取ります。

スナップショット・ツールを使用した物理サーバー数の削減:

仮想サーバーを実行している、より少数の物理サーバーに、多数の物理サーバーを置き換える際に、スナップショット・ツールを使用することができます。

手順

使用する物理サーバー数を削減しようとしているときに役立つ情報を得るには、以下のステップを実行します。

1. すべての既知のシステムのディスカバリーを実行します。

2. 以下のように、スナップショット・ツールを使用してスナップショットを取ります。

snapshot.sh take

以下のようにして、オプションでスナップショットにタイプと記述に関する情報を追加することができます。

snapshot.sh take type description

3. データ管理ポータルで、TADDM_SNAPSHOT_SESSION_FAILED レポートを実行します。 SSH セッションを確立できなかったためにディスカバーされなかったシステムに関する情報が、レポートによって返されます。

4. すべてのシステムで SSH セッションを確立できることを確認してください。TADDM で、認証の詳細情報を更新する必要が生じる場合があります。

5. 最初のディスカバリーの一部としてアクセスされなかったシステムに対してのみディスカバリーを行って、接続に関するすべての問題を解決しておくようにします。

6. 適当な時間 (例えば 1 カ月など) が経過したら、すべての既知のシステムのディスカバリーを実行します。

7. データ管理ポータルで、TADDM_SNAPSHOT_CHANGE レポートを実行します。レポートによって、スナップショットが取られてから可視になっている新規システム、すでに存在しないシステム、およびパーセントで示された物理と仮想の比率に関する情報が返されます。

管理 215

スナップショット・ツールを使用した必要なシステム・リストと実際のシステム・リストの調整:

スナップショット・ツールおよび事前定義されたレポートを使用して、ネットワークで使用可能なサーバーのリストと、必要なサーバーのリストが一致するかを検証することができます。

手順

必要なシステムと実際のシステムを調整するには、以下のステップを実行します。

1. 必要なサーバーのリストが含まれる参照リストを用意します。この参照リストは、コンマ区切りの値 (CSV) 形式のテキスト・ファイルです。これには、以下のフィールドが含まれます。

v ホスト名

v IP アドレス

v フレーム

v オペレーティング・システム

v ホスト・タイプ

v コメント

v サポート・エリア

v ロケーション

参照ファイルの構文について詳しくは、以下のように help パラメーターを指定して、snapshot.sh コマンドを実行してください。

snapshot.sh help

2. 必要に応じて、調整プロセスで無視するサーバーのリストを含む排他リストを用意します。排他リストは、CSV 形式のテキスト・ファイルです。これには、以下のフィールドが含まれます。

v ホスト名

v 排他タイプ

排他ファイルの構文について詳しくは、以下のように help パラメーターを指定して、snapshot.sh コマンドを実行してください。

snapshot.sh help

3. 以下のように、スナップショット・ツールを使用してスナップショットを取ります。

snapshot.sh take

以下のようにして、オプションでスナップショットにタイプと記述に関する情報を追加することができます。

snapshot take type description

4. データ管理ポータルで、以下の BIRT レポートのいずれかを実行します。

v TADDM_SNAPSHOT_RECONCILIATION_SUMMARY

v TADDM_SNAPSHOT_RECONCILIATION_DETAIL


同期サーバー・デプロイメントでのスナップショット・レポートの使用:

事前設定したスナップショット・レポートのエンタープライズ・バージョンを実行して、同期サーバー・デプロイメントの情報を収集することができます。

手順

同期サーバー・デプロイメントで事前定義スナップショット・レポートを実行するには、以下のステップを実行します。

1. スナップショット・テーブルがまだ作成されていない場合は、スナップショット・テーブルをセットアップします。これを行うには、以下のステップを実行します。

a. 各 TADDM サーバーで、パラメーターを指定せずに snapshot.sh コマンドを実行します。

b. 各ドメインおよび同期サーバーで TADDM を再始動します。

この手順により、スナップショット・テーブルがまだ作成されていない場合に、スナップショット・テーブルが作成されます。スナップショット・テーブルは、TADDM 環境ごとに 1 回のみセットアップします。

2. 各 TADDM ドメインでディスカバリーを実行し、必要に応じて各ドメインのスナップショットを取ります。

3. 同期サーバーで同期を実行します。すべてのドメインを含めるようにしてください。

4. エンタープライズ・スナップショットを作成します。同期サーバーで、以下のコマンドを実行します。

snapshot.sh take

5. 各ドメインで、レポートを実行します。各スナップショット・レポートの通常バージョン、例えば TADDM_SNAPSHOT_CHANGE を使用します。

6. 同期サーバーで、レポートを実行します。各スナップショット・レポートのエンタープライズ・バージョン、例えば TADDM_SNAPSHOT_SYNC_CHANGE を使用します。

TADDM と他の Tivoli 製品との統合ご使用の IT 環境の管理における拡張機能として、 IBM Tivoli ApplicationDependency Discovery Manager (TADDM) を他の Tivoli 製品 (IBM TivoliBusiness Service Manager、IBM Tivoli Monitoring、および IBM TivoliNetcool/OMNIbus のようなイベント管理システムなど) と統合することができます。

サポートされるバージョン以下の表を使用して、TADDM を統合できる製品の、サポートされるバージョンを確認できます。

TADDM を統合できる製品の、サポートされるバージョンを以下の表に示します。

管理 217

表 40. サポートされる製品バージョン

製品名サポートされるバージョン

コンテキスト・メニュー・サービスおよびデータ統合サービス (CMS/DIS)

IBM Control Desk (ICD) v 7.6

IBM SmartCloud Control Desk (SCCD) v 7.5.1 - 使用可能な最新のフィックスパック・レベルを使用

IBM Tivoli Business Service Manager(TBSM)

v 4.2.1 - 使用可能な最新のフィックスパック・レベルを使用



IBM Tivoli Change And ConfigurationManagement Database (CCMDB)

v 7.2.1

IBM Tivoli Integration Composer (ITIC) v 7.5.1 - 使用可能な最新のフィックスパック・レベルを使用

IBM Tivoli Monitoring (ITM) v 6.2.1

v 6.2.2 - FP3

v 6.2.3

v 6.3

IBM Tivoli Netcool®/OMNIbus v 7.3

v 7.4

v Fix Pack 1 8.x - TADDM 7.3.0.1 以降でサポート

IBM Tivoli Network Manager IP (ITNMIP) v 3.9

v 4.1

Jazz for Service Management (JazzSM) v 1.1

Tivoli Common Reporting (TCR) v 1.3

v 2.1.1

v 3.1

Tivoli Directory Integrator (TDI) v 7.0

v 7.1

v 7.1.1

Tivoli Netcool/IMPACT v 7.1

Tivoli Workload Scheduler (TWS) v 8.5.1

v 8.6

TADDM と統合する製品について詳しくは、各製品の資料を参照してください。


v コンテキスト・メニュー・サービスおよびデータ統合サービス (CMS/DIS) について詳しくは、TADDM の「インストール・ガイド」の『コンテキスト・メニュー・サービスおよびデータ統合サービス用の構成』トピックを参照してください。

v IBM Control Desk (ICD)

v IBM SmartCloud Control Desk (SCCD)

v IBM Tivoli Business Service Manager (TBSM)

v IBM Tivoli Change and Configuration Management Database (CCMDB)

v IBM Tivoli Integration Composer (ITIC)

v IBM Tivoli Monitoring (ITM)

v IBM Tivoli Netcool/OMNIbus

v IBM Tivoli Network Manager IP (ITNMIP)

v Jazz for Service Management (JazzSM)

v Tivoli Common Reporting (TCR)

v Tivoli Directory Integrator (TDI)

v Tivoli Netcool/Impact

v Tivoli Workload Scheduler (TWS)

OSLC 自動化を通じた TADDM と IBM Tivoli Monitoring の統合

OSLC 自動化を使用して、TADDM を IBM Tivoli Monitoring と統合できます。TADDM を IBM Tivoli Monitoring 6.3 と統合する場合は、OSLC 自動化を使用することをお勧めします。IBM Tivoli Monitoring スコープ・センサーを使用した古い統合方式は非推奨であり、将来のリリースからは削除される予定です。

TADDM は、以下の 2 つの方法で、IBM Tivoli Monitoring インフラストラクチャーを使用します。

v TADDM は、OSLC 自動化セッションを介して Tivoli Enterprise Portal Serverから IBM Tivoli Monitoring エンドポイントのリストを取得します。

v TADDM は、レベル 2 およびレベル 3 ディスカバリーのセンサーに関してターゲット・システムで CLI コマンドを実行し、これらのコマンドの出力を取り込みます。

問題が発生した場合は、「TADDM トラブルシューティング・ガイド」の『ITMOSLC Execute Automation Service Provider の問題』トピックを参照してください。

Fix Pack 5

前提条件:

Windows 7 以上を使用している場合は、次のものが必要になります。

1. PowerShell バージョン 2 以上

2. TEMS SOAP URL

3. TEMS と TEPS の両方に接続できることの確認

管理 219

http://www.ibm.com/support/knowledgecenter/SSWT9A

http://www.ibm.com/support/knowledgecenter/SSWT9A_7.5.1/com.ibm.sccd.doc/sccd_kc_welcome.html

http://www.ibm.com/support/knowledgecenter/SSSPFK

http://www.ibm.com/support/knowledgecenter/SSKTXT

http://www.ibm.com/support/knowledgecenter/SSALK7_7.5.1/com.ibm.sccd.inswas.doc/ic/c_tamit_itic_installing.html

http://www.ibm.com/support/knowledgecenter/SSTFXA

http://www.ibm.com/support/knowledgecenter/en/SSSHTQ/landingpage/NetcoolOMNIbus.html

http://www.ibm.com/support/knowledgecenter/SSSHRK/landingpage/product_welcome_itnm.html

http://www.ibm.com/support/knowledgecenter/en/SSEKCU

http://www.ibm.com/support/knowledgecenter/en/SSH2DF

http://www.ibm.com/support/knowledgecenter/en/SSCQGF

http://www.ibm.com/support/knowledgecenter/en/SSSHYH

http://www.ibm.com/support/knowledgecenter/en/SSGSPN

以下の表に、OSLC 自動化を通じた TADDM と IBM Tivoli Monitoring との統合を正常に有効化するために実行する必要のあるステップを示します。

表 41. OSLC 自動化を通じた TADDM と IBM Tivoli Monitoring の統合

ステップ詳細

ITM Tivoli Enterprise Monitoring Server(TEMS) ホストと ITM TEPS ホストの構成

224 ページの『ITM Tivoli EnterpriseMonitoring Server (TEMS) ホストと ITMTEPS ホストの構成』

OSLC Execute Automation ServiceProvider の IBM Tivoli Monitoring へのインストール注: 224 ページの『OSLC ExecuteAutomation Service Provider を IBMTivoli Monitoring にインストールするための前提条件』で指定されているすべての前提条件が満たされていることを確認してください。

228 ページの『OSLC Execute AutomationService Provider の IBM Tivoli Monitoringへのインストール』

OSLC Execute Automation ServiceProvider を使用するための TADDM の構成

232 ページの『OSLC Execute AutomationService Provider を使用するためのTADDM の構成』

ディスカバリーを実行するための TADDMの構成

v collation.properties ファイルで自動化プロパティーを構成します。

v アクセス・リストに、<"Integration">"OSLC Automation" タイプの新規アクセス・リスト・エントリーを作成します。

126 ページの『OSLC 自動化セッションを介したディスカバリーの構成』

これらのタスクが完了したら、ITM OSLC Execute Automation Service Providerを使用してディスカバリーを実行できるようになります。

関連概念:

231 ページの『OSLC 自動化を介した TADDM の他の製品への統合』TADDM は、Open Services for Lifecycle Collaboration (OSCL) 自動化を使用して他の製品に統合できます。 TADDM は、他の製品インフラストラクチャーに関するデータを提供する OSLC Execute Automation Service Provider に接続します(TADDM は、OSLC 自動化セッションを使用して OSLC Execute AutomationService Provider をディスカバーします)。

ITM OSLC Execute Automation Service ProviderITM OSLC Execute Automation Service Provider は、IBM Tivoli Monitoring が管理するエンドポイントの IP アドレスに関するデータを TADDM にインポートしたり、OSLC 自動化セッション経由で IBM Tivoli Monitoring エンドポイントをディスカバーしたりするために使用されます。

図 1. は、KT1 コマンドを使用して ITM 管理インフラストラクチャーに関するデータを収集する ITM OSLC Execute Automation Service Provider に TADDM


が接続している様子を示しています。

TADDM は、OSLC Execute Automation Service Provider の宛先を JAZZ SMRegistry Services または collation.properties ファイルから取得します。図 2.は、TADDM が JAZZ SM Registry Services を使用して、OSLC ExecuteAutomation Service Provider のアドレスを取得する様子を示しています。

図 4. KT1 コマンドを使用して ITM 管理インフラストラクチャーに関するデータを収集する ITM OSLC ExecuteAutomation Service Provider に TADDM が接続している様子。

管理 221

TADDM は、多数の OSLC Execute Automation Service Provider に直接接続することも、多数のプロバイダーを登録できる単一の JAZZ SM Registry Services に接続することもできます。図 3. は、複数の ITM TEPS (ポータル・サーバー) にデプロイされた OSLC Execute Automation Service Provider のアドレスをTADDM が JAZZ SM Registry Services からダウンロードする様子を示しています。

図 5. TADDM が JAZZ SM Registry Services を使用して、OSLC Execute Automation Service Provider のアドレスを取得する様子。


関連概念:

232 ページの『OSLC Execute Automation Service Provider』OSLC Execute Automation Service Provider は、他の製品が管理するエンドポイントの IP アドレスに関するデータを TADDM に提供するために使用されます。このデータは、OSLC 自動化セッションを使用してエンドポイントをディスカバリーするために使用されます。

図 6. 複数の ITM TEPS (ポータル・サーバー) にデプロイされた OSLC Execute Automation Service Provider のアドレスを TADDM が JAZZ SM Registry Services からダウンロードする様子。

管理 223

ITM OSLC Execute Automation Service Provider のインストールIBM Tivoli Monitoring (ITM) が管理するエンドポイントの IP アドレスに関するデータを TADDM にインポートしたり、ディスカバリーを実行したりするには、OSLC Execute Automation Service Provider を IBM Tivoli Monitoring にインストールする必要があります。

問題が発生した場合は、「TADDM トラブルシューティング・ガイド」の『ITMOSLC Execute Automation Service Provider の問題』トピックを参照してください。

OSLC Execute Automation Service Provider を IBM Tivoli Monitoring にインストールするための前提条件:

OSLC Execute Automation Service Provider を IBM Tivoli Monitoring (ITM) にインストールする前に、すべての前提条件を満たすようにご使用の環境を構成する必要があります。

ITM OSLC Execute Automation Service Provider は、ITM Tivoli EnterprisePortal Server (TEPS) ホストにインストールする必要があります。IBM TivoliMonitoring のサポートされるバージョンは、IBM Tivoli Monitoring 6.3 です。

ITM Tivoli Enterprise Monitoring Server (TEMS) ホストと ITM TEPS ホストの構成

Fix Pack 5 手順 1- TEMS と TEPS の再構成

TEMS と TEPS の構成は、Manage Tivoli Enterprise Monitoring Services(MTEMS) GUI を使用して行うのが最善です。

Windows OS の場合、ITM kinconfig .exe プロセスを開始して、ManageTivoli Enterprise Monitoring Services (MTEMS) GUI を起動します。

UNIX/Linux の場合、CLI コマンド「./itmcmd manage」を使用して、MTEMS GUI を開始できます。

2 つの ITM コンポーネント (TEMS と TEPS) それぞれに対して次のようにします。

v MTEMS UI でコンポーネントを強調表示します

v 右クリックし、「再構成」を選択します

これにより、TEMS または TEPS の構成ウィンドウが表示されます。

すべての TEMS パラメーターを正しく指定し (メインの構成設定に TEMSタイプ、TEMS 名、およびプロトコル、拡張設定にホスト名/IP アドレスおよびポート)、「OK」を選択します。

TEPS 構成ウィンドウで「ダッシュボード・データ・プロバイダーを有効化する」を選択します。

Fix Pack 5 手順 2 - TADDM スクリプトと構成の実行この手順には、TADDM から ITM への統合をセットアップするのに役立つ 2 つのメイン TADDM スクリプトの実行が含まれます。

1. provider.properties ファイルの構成


ITM TEMS ホスト以下のいずれかのスクリプトを ITM TEMS ホストで実行して、KT1 コマンド (tacmd get/put/execute) を有効にします。

v Linux オペレーティング・システムの場合:

TADDM_CD_ISO/itm-discovery-support/configure_tems.sh <-i <ITM_HOME>>[-t <TEMP-DIR>


TADDM_CD_ISO/itm-discovery-support/configure_tems.ps1 <-i <ITM_HOME>>[-t <TEMP-DIR>

ここで <ITM_HOME> は、ITM TEPS のインストール・ディレクトリー(/opt/IBM/ITM など)、<TEMP-DIR> は、一時ファイルの宛先ディレクトリーです。 <TEMP-DIR> パラメーターのデフォルト値は、/var/log/

automation_provider です。

Fix Pack 5

完了すると、スクリプト実行の最後に次の行が表示されます。

INFO: Stopping ITM TEPS...INFO: ITM TEPS has stopped.INFO: Starting ITM TEPS...INFO: ITM TEPS has started.INFO: Checking if TEPS is running...INFO: Checking if OSLC Automation Provider is installed...INFO: Installation of OSLC Automation Provider successfully finished.

注: 初期ユーザー ID の検証 (tacmd get/put/execute) には、http:1920 または https:3661 を使用し、次に、自動化プロバイダーから、ディスカバーされたターゲットへの KT1 処理には ip.pipe:1920 または ip.spipe:3660を使用します。ディスカバリーを完了するために、これらのプロトコルがITM で有効になります。

ITM TEPS ホストITM ダッシュボード・データ・プロバイダーがインストール済みまたは有効になっているかどうかを確認します。なっていない場合は、必要に応じてインストールまたは有効にします。IBM Tivoli Monitoring 資料の『Verifying the dashboard data provider is enabled』トピックを参照してください。

重要: 64 ビットの Windows オペレーティング・システムを使用する場合は、システム・パス (または kfwenv ファイル内のパス・エントリー) が、64 ビットTMAITM6 のディレクトリーを指していることを確認してください。これが存在しない場合は、手動で追加してください。例えば、ITM が C:¥IBM¥ITM¥ ディレクトリーにインストールされている場合は、システム・パス環境変数、またはC:¥IBM¥ITM¥CNPS¥kfwenv ファイルの PATH ディレクティブで、C:¥IBM¥ITM¥TMAITM6_x64 が指定されている必要があります。

Fix Pack 5

2. ITM TEPS ホストからの automation_provider スクリプトの実行

サーバーで、次のように automation_provider スクリプトを実行します。


automation_provider.sh install -t /tmp/log -i /opt/IBM/ITM -c/tmp/provider.properties

管理 225

http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.3.0/com.ibm.itm.doc_6.3/install/itmdp_verifyenabled.htm?lang=en


automation_provider.ps1 install -t /tmp/log -i /opt/IBM/ITM -c/tmp/provider.properties

ここで注意する重要な点は、automation_provider スクリプトの実行前にprovider.properties ファイルが作成されていても、これが無視され、ITMTEPS の構成パス ($ITM_HOME/iw/profiles/ITMProfile/installedApps/ITMCell/itmautomationprovider.ear/itmautomationprovider.war/WEB-INF/provider.properties) に「デフォルトの」provider.properties が作成されるということです。

ファイルを有効にするには、このファイルを見つけ、パラメーターに手動で変更を加えてから、TEPS を再始動する必要があります。

必要なファイル

インストール・スクリプトを実行するディレクトリーには、以下のファイルが存在している必要があります。

v インストール・スクリプト:

– Linux および AIX オペレーティング・システムの場合:TADDM_CD_ISO/itm-discovery-support/automation_provider.sh、およびTADDM_CD_ISO/itm-discovery-support/mod/sh/ にあるそのサブモジュール。

– Windows オペレーティング・システムの場合: TADDM_CD_ISO/itm-

discovery-support/automation_provider.ps1、および TADDM_CD_ISO/itm-discovery-support/mod/ps/ にあるサブモジュール。

v itmautomationprovider.ear - ITM OSLC Execute Automation ServiceProvider を含むパッケージ。このファイルの正確な場所は、TADDM_CD_ISO/itm-discovery-support/ear/itmautomationprovider.ear です。

v provider.properties - ITM OSLC Execute Automation Service Provider のサンプルの構成ファイル。このファイルを手動で構成して、インストール・スクリプトにパラメーターとして渡すことができます。渡さない場合は、インストール時に必須パラメーターを指定する必要があります。このファイルの正確な場所は、TADDM_CD_ISO/itm-discovery-support/template_provider.properties です。

v 該当するオペレーティング・システムとそのアーキテクチャー (32 ビットまたは64 ビット) に対応した KT1 サポート・ライブラリー。

– Linux オペレーティング・システムの場合:

TADDM_CD_ISO/itm-discovery-support/linux32TADDM_CD_ISO/itm-discovery-support/linux64

– AIX オペレーティング・システムの場合:

TADDM_CD_ISO/itm-discovery-support/aix32TADDM_CD_ISO/itm-discovery-support/aix64

– Linux on IBM System Z (zLinux) の場合:

TADDM_CD_ISO/itm-discovery-support/linuxz32TADDM_CD_ISO/itm-discovery-support/linuxz64

– Windows オペレーティング・システムの場合:

TADDM_CD_ISO/itm-discovery-support/win32TADDM_CD_ISO/itm-discovery-support/win64


provider.properties ファイルの構成

次のパラメーターを設定することで、オプションで provider.properties ファイルを構成します。

v com.ibm.automationprovider.registration.host=http://localhost:15210 -ITM に接続できるようにします。値には、TEPS のパブリック URL を指定します。このパラメーターのデフォルト値は、http://localhost:15210 です。

注: localhost を、TEPS サーバーのホスト名または IP アドレスを表すように変更してください。

v com.ibm.automationprovider.itm.curi.url=http://localhost:15210 - ITMCURI (REST) プロバイダーの URL アドレスを指定します。デフォルト値は、http://localhost:15210 です。

注: この場合、localhost を、TEPS サーバーのホスト名または IP アドレスを表すように変更してください。

v com.ibm.automationprovider.itm.soap.url=http://localhost:1920///cms/soap

- ITM SOAP の URL アドレスを指定します。デフォルト値は、http://localhost:1920///cms/soap です。

注: この場合、localhost を、ハブ TEPS サーバーのホスト名または IP アドレスを表すように変更してください。これは、TEPS と同じホスト上にある場合と、そうではない場合があります (ほとんどの実稼働環境では、TEMS と TEPSは別個のサーバー上にあります)。

注: ITM CURI もしくは ITM SOAP をデフォルト以外の構成にした場合、またはITM TEPS で SSL セキュリティーを構成した場合 (あるいはその両方の場合) は、com.ibm.automationprovider.itm.curi.url プロパティーとcom.ibm.automationprovider.itm.soap.url プロパティーに正しい URL アドレスが指定されていることを確認してください。

provider.properties ファイルに指定したパラメーターの値は、コマンド行から定義したパラメーターの値よりも優先されます。

Fix Pack 5

RTEMS 上でディスカバリーを実行する予定がある場合、環境ファイル

でパラメーター「KT1_TEMS_SECURE=YES」が有効になっていることを確認してください。

JAZZ SM Registry Services (FRS) への OSLC Execute Automation ServiceProvider の登録

必要に応じて、OSLC Execute Automation Service Provider を JAZZ SMRegistry Services に登録できます。以下のいずれかの方法を選択します。

v provider.properties ファイルに以下のパラメーターを追加します。

– com.ibm.automationprovider.frs.url - OSLC Execute Automation ServiceProvider を登録するための FRS URL アドレスを指定します。コレクションの完全な URL アドレスを指定する必要があります。例えば、http://9.122.100.100:9083/oslc/pr/collection のように指定します。

管理 227

– com.ibm.automationprovider.frs.user - FRS に接続する際に使用するユーザー名を指定します。

– com.ibm.automationprovider.frs.password - FRS に接続する際に使用するパスワードを指定します。

– com.ibm.automationprovider.registration.initialdelay=5000 - OSLCExecute Automation Service Provider を始動してから FRS への登録を最初に試みるまでの間の時間を指定します。デフォルト値は 5000 (ミリ秒) です。登録を無効にするには、値を -1 に設定します。

v コマンド行で -f オプションを追加し (例えば、./automation_provider.sh

-f)、プロバイダーのインストール時にプロンプトが表示されたら、必須パラメーターを指定します。

OSLC Execute Automation Service Provider の IBM Tivoli Monitoring へのインストール:

OSLC Execute Automation Service Provider を IBM Tivoli Monitoring (ITM) にインストールするには、automation_provider スクリプトを実行する必要があります。OSLC Execute Automation Service Provider は、非対話式モードでインストールすることも、対話式モードでインストールすることもできます。

手順

OSLC Execute Automation Service Provider をインストールするには、ITM TEPSホストから以下の automation_provider スクリプトを実行します。


TADDM_CD_ISO/itm-discovery-support/automation_provider.sh install[-i <ITM-HOME>] [-t <TEMP-DIR>] [[-c <CONFIG-FILE> | [-h <TEPS-IP>][-p <TEPS-PORT>]] [-f]


TADDM_CD_ISO/itm-discovery-support/automation_provider.ps1 install[-i <ITM-HOME>] [-t <TEMP-DIR>] [[-c <CONFIG-FILE> | [-h <TEPS-IP>][-p <TEPS-PORT>]] [-f]

ここで、

-i <ITM-HOME>ITM TEPS のインストール・ディレクトリーです (例: /opt/IBM/ITM)。

-t <TEMP-DIR>一時ファイルの宛先ディレクトリーです。デフォルト値は/var/log/automation_provider です。

-h <TEPS-IP>ITM TEPS ホストの IP アドレスです。

-p <TEPS-PORT>ITM TEPS の HTTP ポートです。

-c <CONFIG-FILE>OSLC Execute Automation Service Provider の構成を含むprovider.properties ファイルの宛先です。

-f このフラグを使用すると、インストール時にプロンプトを表示し、OSLC


Execute Automation Service Provider を JAZZ SM Registry Services に登録するために必要なパラメーターを指定できます。

重要: インストール・スクリプトのパラメーターは、すべてオプションです。パラメーターは、任意の順序で指定できます。例:

automation_provider.sh install -t /tmp/log -i /opt/IBM/ITM -h 9.100.100.200 -p 15210automation_provider.ps1 install -i /opt/IBM/ITM

v OSLC Execute Automation Service Provider を非対話式モードでインストールできます。以下のステップを実行します。

1. provider.properties ファイルを構成します。 227 ページの『provider.properties ファイルの構成』セクションを参照してください。

2. ITM TEPS ホストから以下の automation_provider スクリプトを実行します。

– Linux オペレーティング・システムの場合:

automation_provider.sh install -t /tmp/log-i /opt/IBM/ITM -c /tmp/provider.properties

– Windows オペレーティング・システムの場合:

automation_provider.ps1 install -t /tmp/log-i /opt/IBM/ITM -c /tmp/provider.properties

注: ITM CURI もしくは ITM SOAP をデフォルト以外の構成にした場合、または ITM TEPS で SSL セキュリティーを構成した場合 (あるいはその両方の場合) は、非対話式モードで OSLC Execute Automation ServiceProvider をインストールしてください。また、com.ibm.automationprovider.itm.curi.url プロパティーとcom.ibm.automationprovider.itm.soap.url プロパティーに正しい URL アドレスが指定されていることを確認してください。

v OSLC Execute Automation Service Provider を対話式モードでインストールできます。インストール時に、 227 ページの『provider.properties ファイルの構成』セクションに示された必須パラメーターの値を指定してください。

OSLC Execute Automation Service Provider のインストールの検証:

OSLC Execute Automation Service Provider が IBM Tivoli Monitoring に正常にインストールされたかどうかを検証できます。

手順

1. 以下のコマンドを実行し、ITM TEMS に実行中の Windows エージェント、Linux エージェント、または UX エージェントがあるかどうかを確認します。

/opt/IBM/ITM /bin/tacmd login -u admin -p password -s localhost/opt/IBM/ITM /bin/tacmd listSystems

2. 各 ITM TEMS に自動化プランがあることを確認します。このプランには、ITMエンドポイントの IP アドレスが含まれている必要があります。ご使用の Webブラウザーで以下の Web アドレスを開きます。

http://<ITM_TEPS>:<ITM_PORT>/itmautomationproviderhttp://<ITM_TEPS>:<ITM_PORT>/itmautomationprovider/services/plans

管理 229

例http://9.100.200.100:15210/itmautomationprovider/services/plans

ITM OSLC Execute Automation Service Provider の状況の確認:

ITM OSLC Execute Automation Service Provider のインストール済み環境の状況を確認できます。

手順

以下の automation_provider スクリプトを実行します。


automation_provider.sh status [i- <ITM-HOME>] [t- <TEMP-DIR>]


automation_provider.ps1 status [i- <ITM-HOME>] [t- <TEMP-DIR>]

ここで、

i- <ITM-HOME>ITM TEPS のインストール・ディレクトリーです (例: /opt/IBM/ITM)。

t- <TEMP-DIR>一時ファイルの宛先ディレクトリーです。デフォルト値は/var/log/automation_provider です。

重要: スクリプトのパラメーターは、すべてオプションです。パラメーターは、任意の順序で指定できます。

例automation_provider.sh statusautomation_provider.ps1 status -i /opt/IBM/ITMautomation_provider.sh status -t /tmp/log -i /opt/IBM/ITM

OSLC Execute Automation Service Provider のアンインストール:

ITM OSLC Execute Automation Service Provider をアンインストールするには、automation_provider スクリプトを実行します。

手順

以下の automation_provider スクリプトを実行します。


automation_provider.sh uninstall [i- <ITM-HOME>] [t- <TEMP-DIR>]


automation_provider.ps1 uninstall [i- <ITM-HOME>] [t- <TEMP-DIR>]

ここで、

i- <ITM-HOME>ITM TEPS のインストール・ディレクトリーです (例: /opt/IBM/ITM)。

t- <TEMP-DIR>一時ファイルの宛先ディレクトリーです。デフォルト値は/var/log/automation_provider です。


重要: スクリプトのパラメーターは、すべてオプションです。パラメーターは、任意の順序で指定できます。

例automation_provider.sh uninstallautomation_provider.ps1 uninstall -i /opt/IBM/ITMautomation_provider.sh uninstall -t /tmp/log -i /opt/IBM/ITM

ITM OSLC Execute Automation Service Provider のディスカバリーの構成ITM OSLC Execute Automation Service Provider を使用するときに、次のプロパティーを設定することで、ディスカバリー・プロセスを構成できます。

com.collation.discover.dwcount=32デフォルト値は 32 です。

このプロパティーは、ディスカバリー・ワーカー・スレッドの数を定義するTADDM サーバー・プロパティーです。

最良の結果を得るためには、com.collation.discover.dwcount プロパティーと KT1_RPC_THREADS プロパティーとを同じ値に設定します。

com.ibm.automationprovider.kt1.concurenttasks.limit=100デフォルト値は 100 です。

このプロパティーは ITM OSLC Execute Automation Service Provider プロパティーです。provider.properties ファイルで編集できます。プロバイダーが TEMS に対して発行する同時実行要求の数を定義します。要求数が超えると、プロバイダー・レベルでキューに入れられます。

注: このプロパティーの値を変更するのは、TADDM と TEMS との間に追加スロットルが必要な場合か、100 を超える KT1 ワーカー・スレッドが設定されている場合のみにしてください。

KT1_RPC_THREADS=10デフォルト値は 10 です。

これは、ITM TEMS プロパティーです。ITM_HOME/config/kbbenv.ini ファイルで編集できます。 KT1 要求に応答するワーカー・スレッドの数を定義します。

最良の結果を得るためには、KT1_RPC_THREADS プロパティーとcom.collation.discover.dwcount プロパティーとを同じ値に設定します。

OSLC 自動化を介した TADDM の他の製品への統合TADDM は、Open Services for Lifecycle Collaboration (OSCL) 自動化を使用して他の製品に統合できます。 TADDM は、他の製品インフラストラクチャーに関するデータを提供する OSLC Execute Automation Service Provider に接続します(TADDM は、OSLC 自動化セッションを使用して OSLC Execute AutomationService Provider をディスカバーします)。

OSLC Execute Automation Service Provider を使用したディスカバリーは、一般プロセスです。このプロセスを拡張して、独自の OSLC Execute AutomationService Provider を実装した他の製品のディスカバリーを含めることができます。ディスカバリーの実行時、OSLC Execute Automation Service Provider ホストま

管理 231

たは Jazz SM Registry Services (あるいはその両方) ごとに 1 つのポートが開きます。これにより、より優れたセキュリティー管理を行うことができます。

以下の表に示すトピックには、OSLC を介したディスカバリーに関する情報が詳しく記載されています。

表 42. OSLC を介したディスカバリーに関する詳細が記載されているトピック。

情報ロケーション

ディスカバリーの構成 126 ページの『OSLC 自動化セッションを介したディスカバリーの構成』

TADDM サーバー・プロパティー 93 ページの『OSLC 自動化セッションを使用したディスカバリーのプロパティー』

OSLC 自動化を使用したディスカバリーをサポートするセンサー

TADDM の「センサー解説書」の『OSLC自動化を使用したディスカバリーをサポートするセンサー』トピックを参照してください。

OSLC Execute Automation Service ProviderOSLC Execute Automation Service Provider は、他の製品が管理するエンドポイントの IP アドレスに関するデータを TADDM に提供するために使用されます。このデータは、OSLC 自動化セッションを使用してエンドポイントをディスカバリーするために使用されます。

TADDM は、OSLC Execute Automation Service Provider の宛先を Jazz SMRegistry Services または collation.properties ファイルから取得できます。

TADDM は、多数の OSLC Execute Automation Service Provider に直接接続することも、多数の OSLC Execute Automation Service Provider を登録できるJazz SM Registry Services の単一のインスタンスに接続することもできます。すべての OSLC Execute Automation Service Provider には、TADDM が統合する特定の製品のインスタンスに関する情報 (例えば、ITM HUB に関する情報) が保管されます。

関連資料:

220 ページの『ITM OSLC Execute Automation Service Provider』ITM OSLC Execute Automation Service Provider は、IBM Tivoli Monitoring が管理するエンドポイントの IP アドレスに関するデータを TADDM にインポートしたり、OSLC 自動化セッション経由で IBM Tivoli Monitoring エンドポイントをディスカバーしたりするために使用されます。

OSLC Execute Automation Service Provider を使用するための TADDM の構成:

OSLC 自動化セッションを使用したディスカバリーを実行できるようにするには、OSLC Execute Automation Service Provider を使用するように TADDM を構成する必要があります。


手順

OSLC Execute Automation Service Provider を使用するように TADDM を構成するには、以下のステップを実行します。

1. OSLC Execute Automation Service Provider がインストールされており、稼働していることを確認します。

2. TADDM を OSLC Execute Automation Service Provider に接続します。これには、直接接続する方法と、Jazz for Service Management Registry Servicesを使用して接続する方法の 2 つがあります。 OSLC Execute AutomationService Provider が複数ある場合は、これらの方法を組み合わせることができます。

v TADDM を OSLC Execute Automation Service Provider に直接接続するには、collation.properties ファイルのcom.ibm.cdb.topobuilder.integration.oslc.automationprovider プロパティーに OSLC Execute Automation Service Provider のアドレスを追加します。

v Jazz for Service Management Registry Services を使用して TADDM をOSLC Execute Automation Service Provider に接続するには、OSLCExecute Automation Service Provider の TADDM Jazz SM RegistryServices ルックアップを有効にします。以下のステップを実行します。

a. JAZZ SM Registry Services が稼働していることを確認します。

b. OSLC Execute Automation Service Provider が Jazz SM RegistryServices に接続していることを確認します。

c. Jazz SM Registry Services にアドレスを提供するには、collation.properties ファイルで以下のいずれかのプロパティーを構成します。

com.ibm.cdb.topobuilder.integration.oslc.frsurlcom.ibm.cdb.topobuilder.integration.oslc.automation.frsurl


タスクの結果

TADDM の構成が完了すると、OSLC 自動化セッションを使用したディスカバリーを実行できるようになります。

関連資料:

93 ページの『OSLC 自動化セッションを使用したディスカバリーのプロパティー』これらのプロパティーは、OSLC 自動化セッションを使用したディスカバリーに適用されます。

OSLCAutomationAgent のコマンド行インターフェースOSLCAutomationAgent は、OSLC Execute Automation Service Provider からデータを収集するために使用されます。これらのコマンドを使用して、エージェントの手動での実行と、作成されたスコープ・セットのリフレッシュや更新を行うことができます。

管理 233

OSLC Execute Automation Service Provider のアドレスは、collation.properties ファイルで設定されることも、Jazz SM Registry Servicesからダウンロードされることもあります (その両方の場合もあります)。エージェントは、すべての OSLC Execute Automation Service Provider に接続して、TADDM と互換性のある自動化プランのリストを取得します。自動化プランは、エージェントがディスカバリー・スコープ・セットをキャッシュおよび作成するために使用する IP アドレスから構成されます。例えば、TADDM と IBM TivoliMonitoring とを統合する場合、自動化プランは、IBM Tivoli Monitoring が管理する ITM TEMS サーバーおよびエンドポイント (エージェント) の IP アドレスから構成されます。 OSLCAutomationAgent は、IBM Tivoli Monitoring エージェントの IP アドレスを使用してスコープ・セットをキャッシュおよび作成します。それぞれの ITM TEMS には、個別のスコープ・セットがあります。

OSLCAutomationAgent は、統合エージェントのグループで定期的に実行されます。

OSLCAutomationAgent では、以下のコマンドを使用できます。

v エージェントを手動で実行するには、以下のコマンドを使用します。

/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent

v スコープ・セットをリフレッシュするには、以下のコマンドを使用します。

/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent -s true

注: スコープ・セットは、ITM 自動化プロバイダーの自動化プランが変更された場合にのみリフレッシュされます。スコープ・セットを強制的にリフレッシュするには、以下のコマンドを使用します。

/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent--forceScopeSetRefresh true

スコープ・セットは、ディスカバリー管理コンソールの「スコープ」ペインで使用可能です。

v キャッシュに入れられたスコープ・セットを表示するには、以下のコマンドを使用します。

/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent -d true/taddm/dist/support/bin/runtopobuild.sh -a OSLCAutomationAgent--displayCache true

スコープ・セットは、以下の TADDM ログ・ファイルに表示されます。

– <COLLATION_HOME>/dist/log/services/TopologyBuilder.log

– <COLLATION_HOME>/dist/log/agents/OSLCAutomationAgent.log

以下の例は、<COLLATION_HOME>/dist/log/agents/OSLCAutomationAgent.log ファイルで確認できる出力を示しています。

2014-07-22 11:42:54,660 TopologyBuilder [pool-1-thread-1] DEBUGoslc.OSLCAutomationAgent - OSLCAutomationAgent:displaying cache2014-07-22 11:42:54,669 TopologyBuilder [pool-1-thread-1] INFOoslc.OSLCAutomationAgent - <AGENT_IP_2> http://9.120.100.100:15210/itmautomationprovider/services/plans/2 14060099337642014-07-22 11:42:54,669 TopologyBuilder [pool-1-thread-1] INFOoslc.OSLCAutomationAgent - <AGENT_IP_2> http:///9.120.100.100:15210/itmautomationprovider/services/plans/2 14060099337642014-07-22 11:42:54,675 TopologyBuilder [pool-1-thread-1] DEBUGoslc.OSLCAutomationAgent - OSLCAutomationAgent:cache end


関連概念:

17 ページの『トポロジー構築プロセスの概要』TADDM は、トポロジー構築プロセスを定期的に実行します。ディスカバリー後またはバルク・ロード操作後にトポロジー構築プロセスが実行されるまでは、TADDM データベースに未調整のオブジェクトが存在していたり、トポロジー関係が不完全であったりする可能性があります。

TADDM と IBM Tivoli Monitoring (旧方式) との統合ご使用の IT 環境で行う必要がある特定のタスクに応じて、 IBM TivoliApplication Dependency Discovery Manager (TADDM) と IBM TivoliMonitoring 間で使用可能な統合機能を使用できます。IBM Tivoli Monitoring スコープ・センサーを使用して、TADDM と IBM Tivoli Monitoring を統合できます。

新しい統合方式

重要: TADDM バージョン 7.3.0 以降、IBM Tivoli Monitoring 6.3 との統合には、OSLC 自動化を使用することをお勧めします。IBM Tivoli Monitoring スコープ・センサーを使用した古い統合方式は非推奨であり、将来のリリースからは削除される予定です。

OSLC 自動化を使用した TADDM と IBM Tivoli Monitoring の統合について詳しくは、 219 ページの『OSLC 自動化を通じた TADDM と IBM Tivoli Monitoringの統合』を参照してください。OSLC 自動化を使用したディスカバリーをサポートするセンサーについて詳しくは、TADDM の「センサー解説書」のトピック『OSLC 自動化を使用したディスカバリーをサポートするセンサー』を参照してください。

以前の統合方式

以下のすべてのセクションでは、以前の統合方式について説明します。この統合方式を使用することはできますが、この方式は非推奨であり、今後のリリースでは削除される予定であることに注意してください。

表 1. は、実行べきタスクと使用する必要のある統合機能を相互に関連付けたものです。残りのセクションでは、これらの統合機能について概説します。

表 43. 使用する統合機能に対応するユーザー・タスク

タスク使用する統合機能

オペレーティング・システムの設定、アプリケーションの設定、および IBM TivoliMonitoring がモニターするシステムの変更履歴を表示することで、可用性について洞察します。

v 236 ページの『IBM Tivoli Monitoringを使用したディスカバリー』

v 238 ページの『ランチ・イン・コンテキスト』

TADDM がディスカバーするオペレーティング・システムの可用性について確実にモニターします。

v 236 ページの『IBM Tivoli Monitoringを使用したディスカバリー』

v 238 ページの『モニター範囲レポート』

管理 235

表 43. 使用する統合機能に対応するユーザー・タスク (続き)

タスク使用する統合機能

TADDM がディスカバーするシステムの可用性およびパフォーマンスを表示します。

v 237 ページの『IBM Tivoli MonitoringDLA』

v 238 ページの『モニター範囲レポート』

構成変更についてビジネス・アプリケーションをモニターします。

v 『IBM Tivoli Monitoring を使用したディスカバリー』

v 238 ページの『変更イベント』

v 238 ページの『ランチ・イン・コンテキスト』

IBM Tivoli Monitoring を使用したディスカバリー

TADDM は、IBM Tivoli Monitoring 6.2.1 以降のインフラストラクチャーを使用してレベル 1、レベル 2、および一部のレベル 3 のディスカバリーを実行できます。 TADDM は、ご使用の Tivoli Enterprise Portal Server がモニターする各コンピューターの資格情報ではなく、そのポータル・サーバーの資格情報のみを使用することで、 IBM Tivoli Monitoring 環境内の構成アイテムをディスカバーします。

TADDM は、以下の 2 つの方法で Tivoli Monitoring インフラストラクチャーを活用します。

v TADDM は、基本的なレベル 1 ディスカバリーの情報を作成するためにも、より深いレベル 2 およびレベル 3 のディスカバリーの適用範囲を作成するためにも、Tivoli Enterprise Portal Server から Tivoli Monitoring エンドポイントのリストを取得します。

v TADDM は、レベル 2 およびレベル 3 ディスカバリーのセンサーに関してターゲット・システムで CLI コマンドを実行するためにも、これらのコマンドの出力を取り込むためにも、Tivoli Monitoring インフラストラクチャーを使用します。

この機能には、以下の利点があります。

v 既存の Tivoli Monitoring 環境での TADDM の迅速なデプロイメント

v TADDM アンカーとゲートウェイ・サーバーは不要です。

v スキャンするコンピューターを含むスコープ・セットを定義する必要はありません。必要なのは、 Tivoli Enterprise Portal Server 用の単一エントリーがある 1つのスコープだけです。

v ディスカバリー・ターゲット用のアクセス・リスト (オペレーティング・システム資格情報) を定義する必要はありません。

v Tivoli Enterprise Portal Server の GUI ログオン用の単一アクセス・リスト・エントリーのみを必要とします。


表 44. IBM Tivoli Monitoring を使用したディスカバリーに関する詳細情報が含まれているトピック

情報情報の場所

IBM Tivoli Monitoring を使用したディスカバリーの構成

124 ページの『IBM Tivoli Monitoring (旧方式) を使用したディスカバリーの構成』

IBM Tivoli Monitoring を使用したディスカバリーに適用されるTADDM サーバー・プロパティー

90 ページの『IBM Tivoli Monitoring (旧方式) を使用したディスカバリーのプロパティー』

v IBM Tivoli Monitoring を使用したディスカバリーをサポートするセンサー

v IBM Tivoli Monitoring スコープ・センサー (センサーの構成に関する情報、およびセンサーのデプロイ時や使用時に発生する可能性がある既知の問題のトラブルシューティングに関する情報を含む)

TADDM の「センサー解説書」

IBM Tivoli Monitoring DLA

IBM Tivoli Monitoring ディスカバリー・ライブラリー・アダプター (DLA) は、Tivoli Monitoring がモニターするコンピューター・システムおよびデータベースに関する構成データを Tivoli Monitoring から抽出します。 DLA の出力は、これらのコンポーネントおよびその関係を含む、フォーマット済みの XML ファイルになります。 DLA の出力には、 Tivoli Monitoring エージェントを表すデータおよびTADDM からの使用可能なビューの起動に使用されるデータも含まれます。 DLAエクスポート・データの TADDM へのロードについて詳しくは、TADDM の「ユーザーズ・ガイド」の『バルク・ロード・プログラム』トピックを参照してください。

DLA を実行するには、以下のステップを実行します。

1. 『Using the Tivoli Management Services Discovery Library Adapter』トピック(http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.1/com.ibm.itm.doc_6.2.2fp1/discoverylibraryadapter_tms.htm?lang=en) の説明に従って、ITM で DLA を生成します。

2. DLA 出力ファイルを TADDM ホストにコピーします。

3. バルク・ロード・プログラムを使用して ITM から TADDM に DLA をロードします。以下のコマンドを使用してください。

$COLLATION_HOME/bin/loadidml.sh -u user -p password -f path_to _DLA

新規 Tivoli Monitoring エージェントをインストールする際に、Tivoli MonitoringDLA に対する追加サポートが提供される可能性があります。これらのエージェントは、モニタリング対象レポートに取り込む情報を提供します。オペレーティング・システムのモニター範囲レポートのみ、DLA を必要としません。

エージェントをインストールする際は、それらのエージェントに関するアプリケーション・サポートを有効にして、DLA によって生成された出力に当該エージェント

管理 237

http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.1/com.ibm.itm.doc_6.2.2fp1/discoverylibraryadapter_tms.htm?lang=en

http://www-01.ibm.com/support/knowledgecenter/SSTFXA_6.2.2.1/com.ibm.itm.doc_6.2.2fp1/discoverylibraryadapter_tms.htm?lang=en

を関与させる必要があります。すべてのエージェントが Tivoli Monitoring DLAをサポートしているわけではありません。

非標準エージェントに対するアプリケーション・サポートの構成については、該当する資料を参照してください。エージェントが Tivoli Monitoring DLA をサポートすることを確認するには、IBM Tivoli Composite Application Manager エージェントの文書を参照してください。

モニター範囲レポート

モニター範囲レポートには、ご使用の環境に含まれるさまざまなコンポーネントに関する詳細が示されます。ご使用の環境に含まれるオペレーティング・システム、データベース、Microsoft アプリケーション、VMware サーバー、および Systemp コンポーネントに関するレポートを生成することができます。これらのコンポーネントは、IBM Tivoli Monitoring 6.1 以降のエージェントによってモニターされます。

モニター範囲レポートについて詳しくは、「ユーザーズ・ガイド」を参照してください。.

変更イベント

ディスカバーしたリソースへの変更を検出したときに IBM Tivoli Monitoring に通知するように、TADDM を構成できます。

表 45. 変更イベントに関する詳細情報を含むトピック


v 変更イベントを送信するTADDM の構成

v IBM Tivoli Monitoring データ・プロバイダーの構成

v ビジネス・システム用の変更イベントの構成

247 ページの『外部システムへの変更イベントの送信』

ランチ・イン・コンテキスト

ランチ・イン・コンテキストを使用して、IBM Tivoli Monitoring の TivoliEnterprise Portal ビューに TADDM データを表示できます。

トポロジー・ビューを Tivoli Enterprise Portal に表示するように構成することで、 Tivoli Enterprise Portal 可用性ビュー内に物理インフラストラクチャー、アプリケーション・インフラストラクチャー、およびビジネス・システム・トポロジーを表示できます。

表 46. ランチ・イン・コンテキストに関する詳細情報を含むトピック


トポロジー・ビューの表示に必要なURL

244 ページの『ランチ・イン・コンテキストの構成』


表 46. ランチ・イン・コンテキストに関する詳細情報を含むトピック (続き)


オペレーティング・システムの設定、アプリケーションの設定、および変更イベントの着信の変更履歴を表示するようにランチ・イン・コンテキストを構成するための説明

259 ページの『IBM Tivoli Monitoring での構成変更イベント・レポート内の詳細リンクの作成』

コンテキスト・メニュー・サービスおよびデータ統合サービスの構成アイテムの登録

柔軟な製品間起動ポイントを使用可能にするためにコンテキスト・メニュー・サービス (CMS) およびデータ統合サービス(DIS) を使用する場合は、CMS/DIS データベースで TADDM 構成アイテム (CI) を登録する必要があります。

始める前に

コンテキスト・メニュー・サービスおよびデータ統合サービスを使用するには、まず CMS/DIS データベースをセットアップする必要があります。


TADDM CI は、以下の 2 つの方法で CMS/DIS データベースに登録されます。

v CMS/DIS 登録スクリプトを使用した初期登録

v CMSDISAgent トポロジー・ビルダー・エージェントによる定期的な自動更新

初期登録の実行コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベースでのTADDM 構成アイテム (CI) の初期登録を完了するには、run_cms_dis_registration スクリプトを手動で実行する必要があります。CMSDISAgent トポロジー・ビルダー・エージェントは、この初期登録が完了するまで、CI 登録の自動更新を実行しません。


ストリーミング・サーバー・デプロイメントを使用している場合は、1 次ストレージ・サーバーで登録スクリプトを実行します。同期サーバー・デプロイメントを使用している場合は、同期サーバーで登録スクリプトを実行します。

手順

TADDM CI の初期登録を完了するには、以下のようにします。

1. コマンド・プロンプトで、$COLLATION_HOME/bin ディレクトリーにナビゲートします。

2. ユーザーのオペレーティング・システムに適合する run_cms_dis_registrationスクリプトを実行します。

v Linux および UNIX システム:

管理 239

./run_cms_dis_registration.sh [ register [guid] |clean [guid [classtype]] |re-register-all | register-menu |help ]

v Windows システム:

run_cms_dis_registration.bat [ register [guid] |clean [guid [classtype]] |re-register-all | register-menu |help ]

各項目の意味は次のとおりです。

register [guid]

コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベースで TADDM データを登録します。オプションで、登録したいモデル・オブジェクトのグローバル固有 ID (GUID) を指定できます。

register オプションを指定し、GUID を指定しないでスクリプトを最初に実行したときに、すべての TADDM データがデータベースに登録され、すべての起動ポイントがコンテキスト・メニュー・サービスに登録されます。それ以降にこのオプションを指定して実行すると、前回の実行以降に発生した TADDM データへの変更のみが登録されます。このオプションはデフォルト・オプションです。

GUID を指定した場合、指定された GUID を持つモデル・オブジェクトのみが登録されます。

注: すべての TADDM データの初期登録には長時間かかる場合があります。

clean [guid [classtype]]

現在データベース内にある TADDM データの登録を抹消します。

GUID を指定しない場合、すべての TADDM データが登録を抹消されます。GUID を指定した場合、指定された GUID を持つモデル・オブジェクトのみが登録を抹消されます。指定された GUID を持つモデル・オブジェクトが TADDM で使用できなくなっている場合は、モデル・オブジェクト・タイプも指定する必要があります。

re-register-allすべての TADDM データおよび起動ポイントを登録抹消してから、初期登録を繰り返します。このオプションは、clean オプションを指定してスクリプトを実行してから、register オプションを指定してスクリプトを実行するのと同等です。

register-menuコンテキスト・メニュー・サービス・データベースに登録されているメニュー定義のみを更新します。このオプションは、TADDM データは登録済みであるが、メニュー定義のみを更新したいという場合に使用します。

helpスクリプトのヘルプ情報を表示します。


例

v 次の例では、最初の実行時に、すべての TADDM データをコンテキスト・メニュー・サービスおよびデータ統合サービスに登録します。2 回目以降の実行時には、最後の実行以降のすべての変更を登録します。

./run_cms_dis_registration.sh

v 次の例では、指定された GUID を持つモデル・オブジェクトのみを登録します。

./run_cms_dis_registration.sh register 3950DF835FA0337A829D864415CC1384

v 次の例では、登録されたすべての TADDM データを削除します。

./run_cms_dis_registration.sh clean

v 次の例では、指定された GUID およびモデル・オブジェクト・タイプを持つオブジェクトを削除します。

./run_cms_dis_registration.sh clean 3950DF835FA0337A829D864415CC1384LinuxUnitaryComputerSystem

v 次の例では、登録されたすべての TADDM データを削除してから、登録を繰り返します。

./run_cms_dis_registration.sh re-register-all

次のタスク

登録スクリプトを後で再度実行したい場合は、先に、CMSDISAgent トポロジー・ビルダー・エージェントを使用不可にして、インクリメンタル更新を停止します。エージェントを使用不可にするには、$COLLATION_HOME/etc/collation.properties

ファイルを編集して、以下のプロパティーを設定します。

com.ibm.cdb.DisCmsIntegration.enabled=false

スクリプトが完了したら、次にそのプロパティーを true に設定してエージェントを再度使用可能にする必要があります。

CMSDISAgent の構成CMSDISAgent は、トポロジー・ビルダー・エージェントとして定期的に実行され、コンテキスト・メニュー・サービスおよびデータ統合サービスのデータベースでの TADDM 構成アイテム (CI) の登録を更新します。そのとき、新規 CI または変更された CI をすべて登録し、削除された CI をすべて登録抹消します。


CMDDISAgent が使用可能である場合、run_cms_dis_registration スクリプトを使用して TADDM CI の初期登録を完了した後に、CMDDISAgent が実行を開始します。エージェント構成を変更して、エージェントの実行方法を変更することができます。

手順

v CMSDISAgent を使用可能または使用不可にするには、$COLLATION_HOME/etc/

collation.properties ファイルを編集して、次のプロパティーを設定します。

com.ibm.cdb.DisCmsIntegration.enabled=value

管理 241

ここで、value は true または false です。値が true に設定されている場合、初期登録の完了後、エージェントは定期的に実行されます。 (このプロパティーは、いつでも実行可能な run_cms_dis_registration スクリプトの操作には影響しません。)

v どの CI がデータベースに登録されるかをカスタマイズするには、$COLLATION_HOME/etc/cmsdis ディレクトリーにある以下のファイルを変更します。

classtype-changehistory.listTADDM が変更履歴レポートのコンテキスト起動をサポートしているCI のモデル・オブジェクト・タイプをリストします。

classtype-detailPanel.listTADDM が詳細パネルのコンテキスト起動をサポートしている CI のモデル・オブジェクト・タイプをリストします。

他の製品が TADDM をコンテキスト起動する際に必要ではないモデル・オブジェクト・タイプは、削除することができます。これらのファイルにタイプを追加しないでください。TADDM は、追加タイプのコンテキスト起動をサポートしていない可能性があります。クラス・タイプ・リスト・ファイルを変更した後で、エージェントを使用不可にしてから、re-register-all オプションを指定して run_cms_dis_registration スクリプトを再度実行します。

Discovery Library ストアの作成Discovery Library ストアとはデータ・センター内のコンピューター上にあるディレクトリーまたはフォルダーであり、すべての Discovery Library Adapter (DLA)が、リソース情報を含む XML ファイルに書き込みを行うための、共通のロケーションをいいます。TADDM システムにバルク・ロードされる XML データ・ファイルは、Discovery Library ストアに置かれます。バルク・ローダー・プログラムを使用するには、Discovery Library ストアを作成する必要があります。

始める前に

DLA は、IBM Tivoli Monitoring または IBM Tivoli Business Service Managerなどのソース・アプリケーションからデータを抽出するソフトウェア・プログラムです。

各 DLA は、Identity Markup Language (IdML) と呼ばれる特別な XML 形式のリソース情報を含む XML ファイルに書き込みを行います。IdML 形式で記述された XML ファイルは通常「ブック」と呼ばれます。他の Tivoli 製品からのデータを TADDM データベースにロードできる Tivoli ブック・コレクションを参照するには、http://www.ibm.com/software/brandcatalog/ismlibrary/ を参照してください。

各製品で、その環境からリソースにアクセスする方法が異なるため、DLA は各製品に固有となっています。 DLA の構成およびインストールはアプリケーションごとに異なります。標準的な DLA は、特定のアプリケーションのデータにアクセスするシステム上にインストールされます。例えば、IBM Tivoli Monitoring の DLAは、IBM Tivoli Monitoring エンタープライズ管理システム・データベースにアクセスするコンピューター上にインストールされます。すべての DLA は、コマンド


http://www.ibm.com/software/brandcatalog/ismlibrary/

行インターフェースを使用して実行され、環境内にある任意のタイプのスケジューリング・プログラム (cron など) を使用して実行をスケジュールできます。

ご使用の環境内の既存の製品またはデータベースから情報を抽出するために、DLAを作成することができます。

DLA を作成する方法や IdML 仕様、または Discovery Library ストアの詳細については、TADDM の「Discovery Library Adapter 開発者ガイド」を参照してください。


通常、Discovery Library ストアは TADDM サーバー上に置かれます。DiscoveryLibrary ストアを TADDM サーバーにセットアップしない場合には、TADDM サーバー上で実行される TADDM バルク・ロード・プログラムが、DiscoveryLibrary ストアにアクセスできることを確認する必要があります。 DiscoveryLibrary ストアをホストするのと同じコンピューターで、他のアプリケーションを実行することもできます。

手順

Discovery Library ストアを作成するには、以下のステップを実行します。

1. コンピューター上に、XML ファイルを保管するディレクトリーを作成します。ディレクトリー名はわかりやすいものにしてください (例えば、c:¥IBM¥DLFS など)。オプションとして、使用する DLA ごとにメインの Discovery Libraryストア内にサブディレクトリーを作成できます。

2. 少なくとも 1 つのユーザー ID を使用して File Transfer Protocol (FTP) サーバーを設定します。ユーザー ID には、Discovery Library XML ファイルを保管するディレクトリーに対する書き込み、名前変更、および読み取りの各アクセスを許可する必要があります。Discovery Library ストアへの XML ファイルの転送に FTP を使用しない場合は、使用するツールおよびそのツールの実行に使用されるユーザー ID が、 Discovery Library ストア・ディレクトリーへの書き込みを許可されていることを確認してください。

3. 各種 Discovery Library Adapter から Discovery Library ストアをホストするシステムの名前 (ホスト名) にアクセスできることを確認してください。ほとんどの Discovery Library Adapters は、XML ファイルを Discovery Library ストアにコピーします。

4. 各種 Discovery Library Adapter が、FTP サーバーに接続するためのユーザーID とパスワードを保持していることを確認してください。

5. DLA で FTP を使用していない場合、バルク・ローダー・プログラムがアクセスする XML ファイル (ブック) をその共用ディレクトリーにコピーしてください。共用ディレクトリーは、バルク・ローダー・プログラムからアクセス可能になっている必要があります。

ブック書き込みプログラムおよび管理機能では、ブックを Discovery Libraryストアに取得する役割は担っていません。例えば、生成された IdML ブックをDiscovery Library ストアに FTP で送信するクーロン・ジョブをセットアップする方法があります。

管理 243

次のタスク

Discovery Library ストアを作成し、TADDM データベースに DLA ブックが含まれるようにセットアップする場合、ドメイン・サーバー上のローカル・ドライブを、ネットワーク Discovery Library ストアにすることができます。このディレクトリーは、データがロードされるドメイン・サーバー上の $COLLATION_HOME/etc/bulkload.properties ファイルで定義する必要があります。複数のドメイン・サーバーがある場合、正しいバルク・ローダー・プログラムを構成して、対応する共用ディレクトリーにアクセスします。バルク・ローダーは、Discovery Library ストアから XML ファイルを削除しません。 Discovery Library ストアにファイルを保持します。サーバー上にディレクトリー内のファイル用のディスク・スペースを十分に確保する必要があります。新規 XML ファイルが頻繁にディレクトリーに追加される場合は、定期的なディレクトリーのクリーンアップが必要です。

同期サーバー・デプロイメントを使用している場合は、次のオプションから選択する必要があります。

v ブック内で参照されるリソースが、1 つのドメイン・サーバーで定義されているスコープ定義に含まれている場合は、そのブックを各ドメイン・サーバーにロードします。

v ブック内で参照されるリソースが、1 つのドメイン・サーバーで定義されているスコープ定義に含まれていない場合は、すべてのブックを同期サーバーにロードします。

ランチ・イン・コンテキストの構成環境内のコンポーネントに関する詳細情報を参照するには、他の Tivoli アプリケーションから TADDM ビューを起動します。コンテキストで TADDM ビューを起動するようにアプリケーションを構成するには、URL を指定する必要があります。

他の Tivoli アプリケーションから起動可能なビュー他の Tivoli アプリケーションからデータ管理ポータルのビューを起動することができます。指定の構成アイテム (CI) に関する詳細および変更履歴レポートを起動することもできます。

データ管理ポータルのビューでは、以下のコンポーネント・グループに関する詳細情報を表示することができます。

v ビジネス・アプリケーション

v ビジネス・サービス

v コレクション

TADDM サーバーと TADDM の起動元アプリケーションの両方がシングル・サインオン用に構成されていない場合は、サインオン用のウィンドウが表示されます。データ管理ポータルに追加情報を表示するには、ユーザー名およびパスワードを指定する必要があります。

TADDM ビューを起動する URL の指定他の Tivoli アプリケーションからのコンテキストで TADDM ビューを起動するには、 URL を指定する必要があります。


ランチ・イン・コンテキストの URL 形式は以下のとおりです。

Protocol://TADDMHostname:TADDMPort/ContextRoot/?queryString

以下のリストは、URL 形式内の各変数に有効な値を説明したものです。

プロトコル使用する Web プロトコル。有効な値は http または https です。

TADDMHostname

起動対象となる TADDM サーバーのホスト名。

TADDMPort

起動対象となる TADDM サーバーのポート番号。デフォルト値は 9430 です。

ContextRoot

有効な値は以下のとおりです。

cdm/servlet/LICServletTADDM 7.3.0 の場合は Apache Tomcat サーバーにデプロイされ、TADDM 7.3.0.1 以降の場合は WAS Liberty Profile サーバーにデプロイされている Java サーブレットの相対パス。

cdm/queryHomePage.doシングル・サインオンを使用し、検索テキストを指定して IBM TivoliMonitoring から起動する場合の照会ホーム・ページに対する相対パスです。

queryString

分離文字で区切られた、名前と値のペアのパラメーターが含まれます。名前と値のペアの形式は、name=value です。名前と値の分離には = を使用し、名前と値のペアの分離には & を使用してください。

以下のリストは、queryString 変数で使用可能な有効な名前と値のペアについて説明したものです。

view変更履歴を表示することを示します。

changehistory が唯一の有効な値です。

days_previous特定構成アイテムの変更履歴の表示対象期間 (経過日数) を指定します。

有効な値は正整数です。

hoursback特定の構成アイテムの変更履歴の表示対象期間 (経過時間数) を指定します。

有効な値は正整数です。

guid構成アイテムのグローバル固有 ID (GUID) を指定します。

ドメイン・サーバーおよび同期サーバーについては、 246 ページの表 47に graph パラメーターの有効な値をリストし、それぞれの graph 値に基づいて guid パラメーターがオプションが必須かを示しています。

管理 245

以下のいずれかの値を使用した graph パラメーターが指定されている場合、その guid パラメーターはオプションです。

v businessapplications

v applicationinfrastructure

v physicalinfrastructure

その他のタイプのトポロジー・グラフを使用した graph パラメーターが指定されている場合、その guid パラメーターは必須です。

有効な値は、GUID の有効なストリング表現です。以下に例を示します。

BA2842345F693855A3165A4B5F0D8BDE

ランチ・イン・コンテキストの各 URL 要求には、GUID を 1 つだけ指定してください。

graph起動するトポロジー・グラフのタイプを指定します。

guid パラメーターに GUID を指定することによって構成アイテムもあわせて指定すると、要求された構成アイテムがこの graph パラメーターに指定されたトポロジー・グラフ内にある場合に、その構成アイテムが選択されます。

ドメイン・サーバーおよび同期サーバーについては、表 47 に graph パラメーターの有効な値をリストし、それぞれの graph 値に基づいて guid パラメーターがオプションが必須かを示しています。

表 47. 有効な graph 値および各値と guid パラメーターの関係

有効な値この graph 値で guid パラメーターがオプションか必須か


businessapplications オプション

applicationinfrastructure オプション

physicalinfrastructure オプション

カスタム・コレクション・オブジェクトの場合:

v ba_infrastructure

必須

同期サーバー businessapplications オプション

physicalinfrastructure オプション

カスタム・コレクション・オブジェクトの場合:

v ba_infrastructure

必須

注: GUID で特定のグループ化エンティティーをレンダリングするためにTADDM の以前のリリースで使用されていたその他のグラフ・タイプは非推奨になりました。ただし、古いバージョンとの互換性を確保するために、GUID で古いグラフ・タイプを指定した場合は、要求が新しいトポロジー・タイプにリダイレクトされます。

usernameTADDM へのログインに使用されるユーザー名を指定します。


passwordTADDM へのログインに使用されるパスワードを指定します。

launchsourceITM が唯一の有効な値です。これは、常に searchtext=search_term という名前と値のペアとともに使用されます。

検索の対象は、$COLLATION_HOME/etc/cdm/xml/itm_query_components.xml

構成ファイルにリストされている ComputerSystem タイプおよびTMSAgent タイプの構成アイテムに限定されます。

照会ホーム・ページの結果から、リストされた構成アイテムごとに以下のビューを起動することができます。

v 「変更履歴」ペイン

v 「詳細」ペイン

v 「詳細」ペインを表示するデータ管理ポータル

searchtext検索語を指定します。これは、常に launchsource=ITM という名前と値のペアとともに使用されます。

URL の指定方法の例

以下の例は、TADDM ビューを起動する URL の指定方法を示しています。

データ管理ポータルを起動するための URL (許可情報の別途入力はなし)http://home.taddm.com:9430/cdm/servlet/LICServlet?username=administrator&password=adminpwd&guid=BA2842345F693855A3165A4B5F0D8BDE

信頼できる接続を使用している場合はユーザー名およびパスワードが暗号化されないため、資格情報はランチ・イン・コンテキスト用の URL の一部としてのみ使用する必要があります。

シングル・サインオンを使用して、検索テキストと一致する構成アイテムを検索する際に、IBM Tivoli Monitoring の照会ホーム・ページ・ウィンドウを起動するための URL。

http://home.taddm.com:9430/cdm/queryHomePage.do?launchsource=itm&searchtext=127.0.0.1

guid パラメーターで指定したカスタム・コレクションのトポロジーを表示するための URL

http://home.taddm.com:9430/cdm/servlet/LICServlet?username=administrator&password=adminpwd&graph=ba_infrastructure&guid=BA2842345F693855A3165A4B5F0D8BDE

外部システムへの変更イベントの送信ディスカバーしたリソースへの変更が検出されたときに外部イベント処理システムに通知するように、TADDM を構成できます。

TADDM から変更イベントを送信するには、以下の 1 つ以上のイベント処理システムをインストールしておく必要があります。

v IBM Tivoli Monitoring 6.2.1 フィックスパック 2 以降

v IBM TivoliNetcool/OMNIbus (Event Integration Facility (EIF) プローブ)


管理 247

ディスカバリーが完了すると、TADDM は外部イベント処理システムによって追跡中の項目への変更がないかどうかを検査します。変更が検出されたら、 EIF を使用して直接 IBM Tivoli Netcool/OMNIbus に送信され、さらに Universal Agent を使用して IBM Tivoli Monitoring に送信されます。

Universal Agent は、受信した通知を非同期イベントに変換し、そのデータを IBMTivoli Monitoring の IBM Tivoli Enterprise Monitoring サーバーのコンポーネントに転送します。 IBM Tivoli Monitoring サーバーはイベントを保管して、シチュエーションの評価に使用します。その後で、イベントは、表示のために IBMTivoli Enterprise Portal に渡されます。

IBM Tivoli Netcool/OMNIbus サーバーは、受信したイベントを内部ルールに従って処理し、表示します。

TADDM から外部イベント処理システムへの変更イベントの送信をセットアップするには、 TADDM での変更イベントを使用可能にし、着信イベントを処理するようにそれぞれの外部受信側を適切に構成する必要があります。

変更イベントを送信する TADDM の構成変更イベントを送信するには、変更イベントの送信先のイベント処理システムに関する情報を使用して TADDM を構成する必要があります。


TADDM デプロイメントのタイプに応じて、以下の TADDM サーバーで以下の変更を加えます。

v ドメイン・サーバー・デプロイメントでは、ドメイン・サーバーで変更を加えます。

v 同期サーバー・デプロイメントでは、同期サーバーで変更を加えます。

v ストリーミング・サーバー・デプロイメントでは、1 次ストレージ・サーバーで変更を加えます。

手順

変更イベント情報の送信を可能にするには、以下のステップを実行します。

1. 変更イベントを使用可能にするには、$COLLATION_HOME/etc/

collation.properties ファイルで、次のプロパティーを設定します。com.ibm.cdb.omp.changeevent.enabled=true

2. 変更を追跡するリソースおよびイベントを送信するイベント処理システムを構成するために、 $COLLATION_HOME/etc/EventConfig.xml ファイルを編集します。

EventConfig.xml ファイルに情報を指定する際に使用する必要のあるフォーマットについては、 249 ページの『TADDM OMP 変更イベント・モジュールの構成』を参照してください。

TADDM のアップグレード時に、構成済みのカスタマイズ設定が失われないようにするため、前のリリースの TADDM の EventConfig.xml ファイルが保持されます。新機能とそれらの使用方法に関する情報は、$COLLATION_HOME/etc/

EventConfigDefault.xml ファイルで提供されています。EventConfigDefault.xml ファイルは、参照専用のファイルです。新機能のいず


れかを使用する場合は、EventConfigDefault.xml 内の適切な例に基づいて、EventConfig.xml を更新する必要があります。

3. EventConfig.xml ファイル内で IBMTivoliNetcool/OMNIbus イベント処理システムを指定した場合、対応する EIF プロパティーをそのシステム・タイプ用に作成します。これを行うには、以下のステップを実行します。

a. $COLLATION_HOME/etc/omnibus.eif.properties プロパティー・ファイルを作成します。

b. omnibus.eif.properties ファイルをカスタマイズします。 EIF プロパティー・ファイルのカスタマイズについて詳しくは、IBM TivoliNetcool/OMNIbus 資料の『統合環境での TADDM イベントのサポートの構成』(http://www-01.ibm.com/support/knowledgecenter/SSSHTQ_7.4.0/com.ibm.netcool_OMNIbus.doc_7.4.0/omnibus/wip/install/task/omn_con_ext_configuringtaddmevents.html?lang=en) を参照してください。

TADDM OMP 変更イベント・モジュールの構成:

変更イベントの送信を有効にするには、EventConfig.xml ファイルを編集して、イベント・リスナーとイベント受信側を定義する必要があります。

イベント・リスナー

リスナーを定義するには、TADDM 照会に必要な基準を指定します。照会で選択された結果オブジェクトは、各ディスカバリーの後に変更がないか検査されます。リスナーは、多数定義できます。イベント・ルーティングを実行するには、リスナーと対応する受信側ブロックの両方が存在している必要があります。

リスナーを指定するには、以下のフォーマットを使用します。

<listener object="[OBJECT_TYPE]"enabled="true|false">sendCauses="true|false"sendOriginGuid="true|false">

<alert recipient="[RECIPIENT_SYSTEM_NAME]"/><attribute name="[ATTRIBUTE_NAME]" operator="[OPERATOR]"><value>[ATTRIBUTE_VALUE]</value>

</attribute><causeFilter object="[CAUSEFILTER_OBJECT_TYPE]"

sendOriginGuid="true|false"/>

</listener>

ここで、

[OBJECT_TYPE]ComputerSystem や ITSystem など、TADDM で表現されるモデル・オブジェクトのタイプです。その他の例については、TADDM データ・ディクショナリー (http://taddmserverhost:9430/cdm/datadictionary/model-object/index.html) を参照してください。

enabledイベント送信を許可する属性です。リスナーをアクティブにするには、値をtrue に設定する必要があります。

管理 249

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ_7.4.0/com.ibm.netcool_OMNIbus.doc_7.4.0/omnibus/wip/install/task/omn_con_ext_configuringtaddmevents.html?lang=en



sendCausesモデル・オブジェクトに伝搬された変更に関するイベントをリスナーが送信するかどうかを定義する、オプションの属性です。例えば、Windows オペレーティング・システムに対する変更により ComputerSystem オブジェクトが変更された場合、ComputerSystem リスナーの sendCauses 属性がtrue に設定されていると、リスナーは、変更のイベントをComputerSystem と Windows オペレーティング・システムの両方に送信します。 sendCauses 属性のデフォルト値は false です。

sendOriginGuidsendCauses 属性と共に使用する、オプションの属性です。 sendOriginGuid属性を true に設定した場合は、リスナーに対応するオブジェクトが、オブジェクトに伝搬される変更の論理的な起点と見なされます。伝搬された変更に関して送信されたイベントには、起点オブジェクトの固有 ID が含まれています。例えば、ConfigFile オブジェクトに対する変更によりComputerSystem オブジェクトが変更された場合、ComputerSystem リスナーの sendCauses 属性と sendOriginGuid 属性の両方が true に設定されていると、ConfigFile の変更に関するイベントには、ConfigFile オブジェクトの固有 ID のほかに ComputerSystem オブジェクトの固有 ID が含まれています。この機能は、Netcool/OMNIbus イベント受信側でのみ使用可能です。 sendOriginGuid 属性のデフォルト値は false です。

[RECIPIENT_SYSTEM_NAME]アラート受信側です。 252 ページの『イベント受信側』を参照してください。

[ATTRIBUTE_NAME]照会される [OBJECT_TYPE] の属性名です。

[OPERATOR]TADDM MQL 照会の演算子名です。指定できる値を以下に示します。

表 48. TADDM MQL 照会の演算子名。：

演算子 TADDM MQL での対応する演算子

contains-with contains

ends-with ends-with

equals equals

greater-or-equal >=

greater-than >

less-or-equal <=

less-than <

not-equals not-equals

starts-with starts-with

[ATTRIBUTE_VALUE]この値に対して属性が評価されます。

<causeFilter>sendCauses 属性が有効のときに渡される原因イベントのオブジェクト・タイプをフィルタリングする手段を提供する属性です。この属性を指定した場


合は、指定したオブジェクト・タイプの原因イベントのみが送信されます。ただし、伝搬イベント (例えば、リスナーで指定されたオブジェクト・タイプの一部である伝搬イベント) は、引き続き送信されます。 causeFilter属性を指定しない場合は、リスナーが検出したすべての原因イベントが受信側に送信されます。

例えば、WindowsService を変更すると、Windows オペレーティング・システムが変更され、その結果 ComputerSystem が変更されます。causeFilter 属性に WindowsService を設定した場合は、ComputerSystemと WindowsService の変更のみが表示され、Windows オペレーティング・システムの変更は表示されません。

causeFilter 属性を設定すると、sendOriginGuid 属性の値を必要に応じて設定できます。デフォルトでは、causeFilter 属性は、causeFilter 属性の親であるリスナーの sendOriginGuid 設定を継承します。 causeFilter 属性で sendOriginGuid 属性を使用すると、その causeFilter 属性のリスナー設定のみがオーバーライドされます。

ComputerSystem などの上位オブジェクトにその変更が伝搬されるWindowsService や ConfigFile などのオブジェクトを更新する場合、そのようなオブジェクトを取り込むには、個別のリスナーを使用するのではなく、sendCauses 属性と causeFilter 属性の組み合わせを使用します。

[CAUSEFILTER_OBJECT_TYPE]CDM で定義されたオブジェクトのクラス名です。com.collation.platform.model.topology.sys.windows.WindowsService のようなフルネームを使用することも、WindowsService のようなショート・ネームを使用することもできます。

イベント・リスナーの例

以下の例では、FQDN に "mycompany" ストリングが含まれる任意のComputerSystem で検出された変更が、受信側 "enterprise-eventhost-itm" に送信されます。

<listener object="ComputerSystem" enabled="true"><alert recipient="enterprise-eventhost-itm"/><attribute name="fqdn" operator="contains-with"><value>mycompany</value>

</attribute></listener>

以下の例では、指定したタイプのすべてのオブジェクトに対する変更が検出されます。

<attribute name="guid" operator="not-equals"><value>0</value>

</attribute>

以下の例では、ComputerSystem タイプの任意のオブジェクトで検出された変更が、受信側 "enterprise-eventhost-omnibus" に送信されます。

管理 251

<listener object="ComputerSystem" enabled="true"><alert recipient="enterprise-eventhost-omnibus"/><attribute name="guid" operator="not-equals"><value>0</value>

</attribute></listener>

以下の例では、Linux コンピューター・システム上の ConfigFile の変更によって生じた変更のみが送信されます。

<listener object="ITSystem" enabled="true" sendCauses="true"><alert recipient="enterprise-eventhost-itm"/><attribute name="name" operator="ends-with"><value>ShoppingCart

</value></attribute><causeFilter object="ConfigFile" /><causeFilter object="LinuxUnitaryComputerSystem" />

</listener>

イベント受信側

イベント受信側は、IBM Tivoli Monitoring または OMNIBus のインスタンスであり、変更イベント・モジュールからイベントを受信できます。変更が変更リスナーによって特定されると、対応する受信側に通知が送信されます。異なるタイプの受信側または同じタイプの受信側を同時に複数定義できます。イベント・ルーティングを実行するには、リスナーおよび対応する受信側ブロックの両方が存在している必要があります。

受信側を指定するには、以下のフォーマットを使用します。

<recipient name="[RECIPIENT_NAME]" type="[RECIPIENT_TYPE]"><address>[RECIPIENT_FQDN]</address><port>[EVENT_ROUTING_PORT]</port><config>[PATH_TO_EIF_CONFIGURATION]</config>

</recipient>

ここで、

[RECIPIENT_NAME]リスナーで参照されるシステムの名前です。

[RECIPIENT_TYPE]イベントの受信に使用するソフトウェアのタイプです。サポートされるタイプを以下に示します。

v itm - IBM Tivoli Monitoring 6 と Universal Agent POST データ・プロバイダー。

v omnibus - Netcool/OMNIbus と EIF アダプター。

[RECIPIENT_FQDN](IBM Tivoli Monitoring のみ) Universal Agent が配置されているホストの完全修飾ドメイン名です。

[EVENT_ROUTING_PORT](IBM Tivoli Monitoring のみ) Universal Agent POST データ・プロバイダーが KUMENV で KUMP_POST_DP_PORT として指定したポートです。


[PATH_TO_EIF_CONFIGURATION](OMNIBUS のみ) プロパティー・ファイルから読み取られる EIF 構成のパスです。ファイルの絶対パスを使用します。

イベント受信側の例

以下の例では、Netcool/OMNIbus イベント受信側が定義されています。

<recipient name="enterprise-eventhost-omnibus" type="omnibus"><config>/opt/IBM/taddm/dist/etc/omnibus.eif.properties</config>

</recipient>

以下の例では、IBM Tivoli Monitoring イベント受信側が定義されています。

<recipient name="enterprise-eventhost-itm" type="itm"><address>itm-ua.mycompany.com</address><port>7575</port>

</recipient>

IBMTivoliNetcool/OMNIbus の構成バージョン 7.3 以降の IBMTivoliNetcool/OMNIbus は、TADDM によって送信された変更イベントを受信するように構成できます。前のバージョンの TivoliNetcool/OMNIbus で表示されるイベント・データを集約およびカスタマイズして、イベント処理ロジックを定義することができます。

始める前に

TADDM が送信する変更イベントを受信するように IBM TivoliNetcool/OMNIbus バージョン 7.3 以降を構成するには、IBM TivoliNetcool/OMNIbus の資料 (http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html?lang=en) のトピック『TADDM イベントのサポートの使用可能化』を参照してください。 Tivoli Netcool/OMNIbusの資料には、tivoli_eif_taddm.rules ファイルに関する情報も記載されています。このファイルには、TADDM のディスカバリー中に検出された構成変更の詳細を処理するロジックが含まれています。

高可用性 (フェイルオーバー) コンピューティングが使用されている環境では、TADDM は自動フェイルオーバーをサポートするよう構成できます。このサポートは、TADDM イベントが Tivoli Netcool/OMNIbus に送信される場合に発生します。1 次および 2 次の EIF プローブ・アドレスと、それらに関連付けられるポートを、EIF プロパティー・ファイルに指定できます。以下の例では、これらのプロパティーを追加する場所を示しています。

# Hostname where the NetCool/OMNIbus EIF probe resides. Specify up to 8 locations.# Each location should be separated by a comma.# The event is sent to the first available probe in the list.# Example:# ServerLocation=netcool.mycompany.com,netcool2.mycompany.comServerLocation=netcool.mycompany.com,netcool2.mycompany.com

# Port the NetCool/OMNIbus EIF probe is listening on.# There must be a port entry for each probe specified under ServerLocation.# Example:# ServerPort=9998,9998ServerPort=9998,9998

管理 253

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html?lang=en

http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/landingpage/NetcoolOMNIbus.html?lang=en

入力されるプローブ・アドレスごとに、関連付けられるポートを ServerPort プロパティーで指定する必要があります。各プローブ・アドレスにポートを指定しないと、イベントが送信されるときにエラーが発生します。イベントを 1 次ポートに送信できない場合、リスト内で最初に使用可能なポートに送信されます。最大 8 つのプローブ・アドレスを ServerLocation プロパティーに指定できます。


バージョン 7.3 より前のバージョンの IBMTivoliNetcool/OMNIbus では、デフォルトの動作で、イベント・モジュールからのすべてのイベントを単一イベントに結合し、カウント属性を設定して、結合したイベントに含まれるイベントの数を表示します。デフォルトの動作の変更方法を以下の手順で説明します。

手順

1. TADDM サーバーで、次のファイルを開いて編集します。$COLLATION_HOME/etc/omnibus.eif.properties

2. 以下の TADDMEvent_Slot プロパティーにプロパティー値を設定します。

TADDMEvent_Slot_object_name=$TADDM_OBJECT_NAMETADDMEvent_Slot_change_type=$TADDM_CHANGE_TYPETADDMEvent_Slot_change_time=$TADDM_CHANGE_TIMETADDMEvent_Slot_class_name=$TADDM_CLASS_NAMETADDMEvent_Slot_attribute_name=$TADDM_ATTRIBUTE_NAMETADDMEvent_Slot_old_value=$TADDM_OLD_VALUETADDMEvent_Slot_new_value=$TADDM_NEW_VALUETADDMEvent_Slot_host=$TADDM_HOSTTADDMEvent_Slot_port=$TADDM_PORTTADDMEvent_Slot_guid=$TADDM_GUIDTADDMEvent_Slot_origin=$TADDM_ORIGIN

次のタスク

IBM Tivoli Netcool/OMNIbus の構成で問題が発生した場合は、TADDM の「トラブルシューティング・ガイド」の『TADDM と他の製品との統合の問題』トピックを参照してください。

IBM Tivoli Monitoring データ・プロバイダーの構成新規データ・プロバイダーを定義するように Universal Agent 初期設定ファイルを構成できます。

始める前に

Tivoli Monitoring の 6.2.2 以前のバージョンを使用している場合は、KUMPOST 構成ファイル内にタブ文字もスペース文字もないことを確認してください。

手順

IBM Tivoli Monitoring データ・プロバイダーを構成するには、以下のステップを実行します。

Universal Agent を Windows システムで実行している場合は、以下のステップを実行します。


1. Universal Agent がインストールされている Windows システムで、「開始」> 「IBM Tivoli Monitoring」 > 「Tivoli Monitoring Services の管理」をクリックします。

2. Universal Agent を右クリックして「再構成」をクリックします。

3. 2 つの「エージェント拡張構成」のそれぞれのウィンドウで、「OK」をクリックします。

4. Universal Agent 初期設定ファイルを更新するために、「はい」をクリックします。システム・テキスト・エディターに KUMENV ファイルが開きます。

5. 以下のように KUMA_STARTUP_DP 値を POST に設定します。

KUMA_STARTUP_DP=POST

注: Universal Agent が別のデータ・プロバイダーを使用するように既に構成されている場合、次の例にあるように、両方の値をコンマで区切って指定してください。

KUMA_STARTUP_DP=ASFS,POST

6. 必須 POST パラメーター情報を KUMENV ファイルに追加します。

*----------------------------------------** TADDM POST DP Parameters **----------------------------------------*KUMP_POST_DP_PORT=7575KUMP_POST_GROUP_NAME=TADDMKUMP_POST_APPL_TTL=14400

7. KUMENV ファイルを保存して閉じます。

8. エージェントを構成するために、「はい」をクリックします。

9. 「Tivoli Enterprise Monitoring Services の管理」ウィンドウで、「UniversalAgent」 > 「開始」をクリックします。

10. システム・テキスト・エディターで、テキスト・ファイルを作成します。ファイルに以下の情報を入力します。

//APPl CONFIGCHANGE//NAME dpPost E 3600//ATTRIBUTES ';'Post_Time T 16 Caption{Time}Post_Origin D 32 Caption{Origination}Post_Ack_Stamp D 28 Caption{Event time stamp}Comp_Type D 512 Caption{Component type}Comp_Name D 512 Caption{Component name}Comp_Guid D 512 Caption{Component GUID}Change_Type D 512 Caption{Change type}Chg_Det_Time D 512 Caption{Change detection time}Chg_Attr D 512 Caption{Changed attribute}Srv_Addr D 512 Caption{TADDM server}Srv_Port D 16 Caption{TADDM port}

11. ファイルを %ITM_HOME%¥TMAITM6¥metafiles¥KUMPOST として保存します。

注: ここに示すように、ファイル名 KUMPOST のスペルが大文字になっていることを確認します。

12. Windows コマンド・プロンプトを開いて、 %ITM_HOME%¥TMAITM6 フォルダーにナビゲートします。

13. KUMPCON.exe プログラムを実行して、 KUMPOST メタファイルの検証およびインポートを行います。

管理 255

14. 「Tivoli Monitoring Services の管理」ウィンドウで、 Universal Agent を右クリックして「リサイクル」を選択します。

Universal Agent を Linux または UNIX システムで実行している場合は、以下のステップを実行します。

1. 次のコマンドを使用して Universal Agent を再構成します。

itmcmd config –A um

データ・プロバイダーのプロンプトが出されたら、 POST と入力します。

注: Universal Agent が別のデータ・プロバイダーを使用するように既に構成されている場合、例えば ASFS,POST のように、両方の値をコンマで区切って指定してください。

2. $ITM_HOME/config ディレクトリーに、 um.ini ファイルのバックアップ・コピーを作成してから、そのファイルのオリジナル・コピーに以下のエントリーを追加します。

# TADDM POST DP ParametersKUMP_POST_DP_PORT=7575KUMP_POST_GROUP_NAME=TADDMKUMP_POST_APPL_TTL=14400

3. $ITM_HOME/interp/um/metafiles ディレクトリーに、テキスト・ファイルを作成します。ファイルに以下の情報を入力します。

//APPl CONFIGCHANGE//NAME dpPost E 3600//ATTRIBUTES ';'Post_Time T 16 Caption{Time}Post_Origin D 32 Caption{Origination}Post_Ack_Stamp D 28 Caption{Event time stamp}Comp_Type D 512 Caption{Component type}Comp_Name D 512 Caption{Component name}Comp_Guid D 512 Caption{Component GUID}Change_Type D 512 Caption{Change type}Chg_Det_Time D 512 Caption{Change detection time}Chg_Attr D 512 Caption{Changed attribute}Srv_Addr D 512 Caption{TADDM server}Srv_Port D 16 Caption{TADDM port}

4. ファイルを KUMPOST として保存します。

注: ここに示すように、ファイル名 KUMPOST のスペルが大文字になっていることを確認します。

5. 以下のコマンドを使用して Universal Agent を再始動します。

itmcmd agent stop um

itmcmd agent start um

6. KUMPOST メタファイルを検証およびリフレッシュするには、以下の手順を実行します。

a. 以下のパラメーターを指定して $ITM_HOME/bin/um_console コマンドを実行します。

um_console -h <ITM directory>

b. コマンド行で、以下のテキストを入力します。

validate KUMPOST

以下のようなメッセージが表示されます。


KUMPS001I Console input accepted.KUMPV025I Processing input metafile /opt/IBM/ITM//lx8266/um/metafiles/KUMPOSTKUMPV026I Processing record 0001 -> //APPl CONFIGCHANGEKUMPV148I Note: APPL names starting with letters A-M are designated forBest Practices and Business Partner UA solutions.KUMPV026I Processing record 0002 -> //NAME dpPost E 3600KUMPV026I Processing record 0003 -> //ATTRIBUTES ';'KUMPV026I Processing record 0004 -> Post_Time T 16 Caption{Time}KUMPV026I Processing record 0005 -> Post_Origin D 32 Caption{Origination}KUMPV026I Processing record 0006 -> Post_Ack_Stamp D 28 Caption{Event time stamp}KUMPV026I Processing record 0007 -> Comp_Type D 512 Caption{Component type}KUMPV026I Processing record 0008 -> Comp_Name D 512 Caption{Component name}KUMPV026I Processing record 0009 -> Comp_Guid D 512 Caption{Component GUID}KUMPV026I Processing record 0010 -> Change_Type D 512 Caption{Change type}KUMPV026I Processing record 0011 -> Chg_Det_Time D 512 Caption{Change detection time}KUMPV026I Processing record 0012 -> Chg_Attr D 512 Caption{Changed attribute}KUMPV026I Processing record 0013 -> Srv_Addr D 512 Caption{TADDM server}KUMPV026I Processing record 0014 -> Srv_Port D 16 Caption{TADDM port}KUMPV000I Validation completed successfullyKUMPV090I Application metafile validation report saved in file/opt/IBM/ITM//lx8266/um/metafiles/KUMPOST.rpt.

c. メタファイルに対して実行するアクションの指定を求めるプロンプトが出されたら、以下のテキストを入力します。

Refresh

d. Yesを入力して確認します。

次のタスク

Universal Agent の構成が正常に完了したことを確認するには、Tivoli EnterprisePortal 内の変更イベント・レポートを調べます。

IBM Tivoli Monitoring 6.2.1 以降を使用して変更イベント・レポートを開くには、以下のステップを実行します。

1. TADDM に対してイベント通知を送受信するように構成された UniversalAgent にナビゲートします。

2. CONFIGCHANGE ノードを展開します。

3. 「DPPOST」ノードをクリックします。

IBM Tivoli Monitoring での構成変更シチュエーションの作成Tivoli Enterprise Portal のシチュエーション機能を使用して、変更イベントをモニターし、変更イベントの情報に基づいたシチュエーションをトリガーすることができます。

手順

IBM Tivoli Monitoring で構成変更シチュエーションを作成するには、以下のステップを実行します。

IBM Tivoli Monitoring 6.2.1 を使用している場合に構成変更シチュエーションを作成するには、以下のステップを実行します。

1. IBM Tivoli Enterprise Portal の「ナビゲーター」ペインで、TADDM に対してイベント通知を送受信するように構成された Universal Agent にナビゲートします。


3. 「DPPOST」ノードを右クリックします。「シチュエーション」をクリックします。

管理 257

4. 「node_name のシチュエーション」ウィンドウで、「ユニバーサル・データ・プロバイダー」を右クリックします。「新規作成」をクリックします。「シチュエーションまたはルールの作成」ウィンドウが表示されます。

5. 「名前」フィールドに、シチュエーションの名前を入力します。例えば、ConfigurationChanged などとします。

6. 「説明」フィールドに、シチュエーションの説明を入力します。例えば、追跡したオブジェクトへの変更が TADDM によって検出されました (A change to a

tracked object was detected by TADDM) などとします。

7. 「監視中のアプリケーション」リストから、「ユニバーサル・データ・プロバイダー」を選択します。

8. 「管理対象システム間の相関シチュエーション」チェック・ボックスがクリアされていることを確認します。

9. 「OK」をクリックします。「条件の選択」ウィンドウが表示されます。

10. 「属性グループ」リストから、「DPPOST」を選択します。

11. 「属性項目」リストから、「コンポーネント名」を選択します。

12. 「OK」をクリックします。このシチュエーションの「式」タブが表示されます。

13. モニターする環境内のリソースの名前とコンポーネント名が一致したときにシチュエーションのトリガーが発生するようにシチュエーションを構成します。


IBM Tivoli Monitoring 6.2.2 以降を使用している場合に構成変更シチュエーションを作成するには、以下のステップを実行します。

1. IBM Tivoli Enterprise Portal の「ナビゲーター」ペインで、TADDM に対してイベント通知を送受信するように構成された Universal Agent にナビゲートします。


3. 「DPPOST」ノードを右クリックします。「シチュエーション」をクリックします。

4. 「node_name のシチュエーション」ウィンドウで、「シチュエーションの新規作成」をクリックします。「シチュエーションの作成」ウィンドウが表示されます。

5. 「名前」フィールドに、シチュエーションの名前を入力します。例えば、ConfigurationChanged などとします。

6. 「説明」フィールドに、シチュエーションの説明を入力します。例えば、追跡したオブジェクトへの変更が TADDM によって検出されました (A change to a

tracked object was detected by TADDM) などとします。

7. 「監視中のアプリケーション」リストから、「ユニバーサル・データ・プロバイダー」を選択します。

8. 「OK」をクリックします。「条件の選択」ウィンドウが表示されます。

9. 「属性グループ」リストから、「DPPOST」を選択します。

10. 「属性項目」リストから、「コンポーネント名」を選択します。

11. 「OK」をクリックします。このシチュエーションの「式」タブが表示されます。


12. モニターする環境内のリソースの名前とコンポーネント名が一致したときにシチュエーションのトリガーが発生するようにシチュエーションを構成します。


14. IBM Tivoli Enterprise Portal の「ナビゲーター」ペインで、変更イベント・レポートを含むノードを右クリックします。「シチュエーション」をクリックします。

15. 「node_name のシチュエーション」ウィンドウで、作成したConfigurationChanged シチュエーションを右クリックし、「シチュエーションの開始」をクリックします。

タスクの結果

構成変更イベントを受け取るときに、そのコンポーネント名が検査されます。そのコンポーネント名とシチュエーション式に指定されたコンポーネントの名前が一致した場合、構成済みのシチュエーションのトリガーが発生します。

IBM Tivoli Monitoring での構成変更イベント・レポート内の詳細リンクの作成変更履歴および詳細を TADDM サーバーから直接表示するワークスペースへのリンクをレポート・テーブルに作成できます。これらのリンクは、レポートに表示されるものよりも詳細な情報を提供します。

手順

構成変更イベント・レポートで、より詳細な変更イベント情報へのリンクを作成するには、以下のステップを実行します。

1. 情報を表示するワークスペースを作成するために、以下のステップを実行します。

a. 「ナビゲーター」ペインで、ワークスペースを含めるノードを右クリックします。「ファイル」 > 「ワークスペースを別名で保管」をクリックします。「ワークスペースを別名で保管」ウィンドウが表示されます。

b. 「名前」フィールドに、ワークスペースの名前を入力します。例えば、ConfigChangeDetails などとします。

c. 「説明」フィールドに、ワークスペースの説明を入力します。例えば、変更イベント・テーブル用の汎用ワークスペース (Generic workspace for

the change event table) などとします。

d. 「ワークスペース・リンクのターゲットとしてのみ選択可能」チェック・ボックスを選択します。


2. IBM Tivoli Monitoring 6.2.1 以降を使用してワークスペースを構成するには、以下のステップを実行します。

a. 1 つのナビゲーター・ペインおよび 2 つのブラウザー・ペインを持つようにワークスペースを構成します。

b. 「編集」 > 「プロパティー」をクリックします。

c. 「ブラウザー」ペインで、「はじめに」の最初のインスタンスを選択します。

管理 259

d. 「スタイル」ペインで、「提供されたロケーションを使用」を選択します。


f. いずれかのブラウザー・ペインの「ロケーション」フィールドに、TADDM での変更履歴ビューの URL を入力します。 URL を 1 行に入力したら、「Enter」を押さないでください。

http://$taddm_server$:$taddm_port$/cdm/servlet/LICServlet?view=changehistory&hoursback=10000&console=web&guid=$taddm_guid$

hoursback パラメーターは、変更イベントを表示する時間数を指定します。例えば、hoursback を 6 に設定すると、直前の 6 時間の変更イベントがすべて表示されます。

g. 「ブラウザー」ペインで、「はじめに」の 2 つ目のインスタンスを選択します。

h. 「スタイル」ペインで、「提供されたロケーションを使用」を選択します。

i. 「OK」をクリックします。

j. 2 つ目のブラウザー・ペインの「ロケーション」フィールドに、 TADDMでのオブジェクトの詳細ビューの URL を入力します。 URL を 1 行に入力したら、「Enter」を押さないでください。

http://$taddm_server$:$taddm_port$/cdm/servlet/LICServlet?console=web&guid=$taddm_guid$

k. 新規ワークスペースを保存するには、「ファイル」 > 「保管」をクリックします。

「ロケーション」フィールドに URL を入力した直後に、「Enter」を押さずに、ワークスペースを保存してください。

3. IBM Tivoli Enterprise Portal を開きます。「レポート」ペインで、「レポート」テーブル内の行を右クリックします。

4. 「リンク先」 > 「リンク・ウィザード」をクリックします。「ワークスペース・リンク・ウィザード」のウェルカム・ページが表示されます。

5. 「新規リンクの作成」をクリックします。「次へ」をクリックします。「ワークスペース・リンク・ウィザード」の「リンク名」ページが表示されます。

6. 「名前」フィールドに、リンクの名前を入力します。例えば、詳細の表示などとします。

7. 「説明」フィールドに、リンクの説明を入力します。例えば、詳細へのリンク(Link to details) などとします。

8. 「次へ」をクリックします。「ワークスペース・リンク・ウィザード」の「リンク・タイプ」ページが表示されます。

9. 「絶対」をクリックします。「次へ」をクリックします。「ワークスペース・リンク・ウィザード」の「ターゲット・ワークスペース」ページが表示されます。

10. 「ナビゲーター」パネルで、作成したワークスペースを含むノードを選択します。「ワークスペース」パネルで、作成したワークスペースを選択します。

11. 「次へ」をクリックします。「ワークスペース・リンク・ウィザード」の「パラメーター」ページが表示されます。


12. 「taddm_server」、「taddm_port」、および「taddm_guid」の 3 つのシンボルを追加する必要があります。シンボルを追加するには、以下のステップを実行します。

a. 「シンボルの追加」をクリックします。「シンボルの追加」ウィンドウが表示されます。

b. 「シンボル」フィールドに、シンボルの名前を入力します。

c. 「OK」をクリックします。

13. 作成するそれぞれのシンボルを、レポートの正しい列を示す属性にリンクする必要があります。

v 「taddm_server」シンボルを TADDM サーバー属性にリンクします。

v 「taddm_port」シンボルを TADDM Web コンソールのポート番号にリンクします。

v 「taddm_guid」シンボルをコンポーネント GUID 属性にリンクします。

シンボルを属性にリンクするには、以下のステップを実行します。

a. 「ワークスペース・リンク・ウィザード」の「パラメーター」ページで、レポート列にリンクするシンボルを選択します。

b. 「式の変更」をクリックします。「式エディター」ウィンドウが表示されます。

c. 「シンボル」をクリックします。「シンボル」ウィンドウが表示されます。

d. 「属性」にナビゲートして、シンボルにリンクする属性を選択します。「OK」をクリックします。

e. 「式エディター」ウィンドウで、「OK」をクリックします。「ワークスペース・リンク・ウィザード」の「パラメーター」ページが表示されます。

14. 「次へ」をクリックします。「ワークスペース・リンク・ウィザード」の「要約」ページが表示されます。

15. 「完了」をクリックします。

タスクの結果

変更イベント・レポートにアクティブ・イベントがあれば、各テーブル行の横にリンク・アイコンが表示されます。ターゲット・ワークスペースに移動するには、リンク・アイコンをクリックして「詳細の表示」を選択します。テーブル行では、値がシンボルに置き換えられます。ワークスペースでは、「変更履歴」および「オブジェクトの詳細」の各パネルがコンテキスト内で起動されます。

ビジネス・システム用の変更イベントの構成変更イベント機能を使用して、ビジネス・システムが変更されるごとに変更イベントを送信することができます。


デフォルトでは、TADDM は、依存するコンピューターのいずれかが変更された場合も、ビジネス・システムが変更されたことを示しません。

管理 261

手順

ビジネス・システム用の変更イベントの送信を可能にするには、以下のステップを実行します。

1. 適切なエディターで $COLLATION_HOME/etc/propagationserver.xml を開きます。

2. 「コンピューター・システム」セクションで、アプリケーションとビジネス・システムの関係エレメントについて、enabled 属性の値を true に設定します。例:

<relationship enabled="true" source="sys.ComputerSystem" attribute="groups"target="app.Application" targetAttribute="true"collectionType="app.FunctionalGroup" radius="1"/>

<relationship enabled="true" source="sys.ComputerSystem" attribute="components"target="sys.BusinessSystem" targetAttribute="true"/>

3. TADDM を再始動します。

4. 変更イベント構成 $COLLATION_HOME/etc/EventConfig.xml にビジネス・システム用のリスナーを作成します。次の例では、イベント受信側は mycompany-itmで、ビジネス・システム名は MyBiz です。

<listener object="ITSystem" enabled="true"><alert recipient="mycompany-itm"/><attribute name="name" operator="equals"><value>MyBiz</value></attribute></listener>

IBM Tivoli Workload Scheduler を使用したジョブのスケジューリング

IBM Tivoli Workload Scheduler を使用して、TADDM でのジョブをスケジュールすることができます。 IBM Tivoli Workload Scheduler は、自動化されたワークロード管理とモニタリングの基幹となるソフトウェア自動化ツールです。

IBM Tivoli Workload Scheduler 8.5.1 以降を使用します。TADDM サーバーに、マスター・ドメイン・マネージャーおよびフォールト・トレラント・エージェントをインストールする必要があります。 Tivoli Workload Scheduler をインストールして構成する方法については、http://www-01.ibm.com/support/knowledgecenter/SSGSPN_8.5.1.1/com.ibm.tivoli.itws.doc_8.5.1.1/ic-homepage.html?lang=enを参照してください。スケジューリング・オブジェクトは、コンポーザー・コマンド行プログラムで管理され、Tivoli Workload Schedulerに保管されます。

Tivoli Workload Scheduler のジョブは、invokejob.sh スクリプトを使用して必要な操作を実行します。invokejob.sh スクリプトは、TADDM インストールで提供されています。

このスクリプトのすべての用途に共通するパラメーターは以下のとおりです。

必須: -u userこの値は、API コマンド実行ユーザーを指定します。

必須: -p passwordこの値は、ユーザーを認証するパスワードを指定します。


http://www-01.ibm.com/support/knowledgecenter/SSGSPN_8.5.1.1/com.ibm.tivoli.itws.doc_8.5.1.1/ic-homepage.html?lang=en



必須: --profile profileこの値は、ディスカバリー・プロファイルを定義します。

オプション: -H hostこの値は、TADDM サーバー・ホスト名を指定します。デフォルト名はlocalhost です。 -T パラメーターを使用する場合は、-H パラメーターも指定する必要があります。

オプション: -P portこの値は、TADDM サーバー・ポートを指定します。デフォルト値は 9433です。

オプション: -v versionこの値は、バージョンの名前または番号を指定します。デフォルト値は 0です。

オプション: -t timeoutこの値は、ジョブが自動的に中断されるまでの時間を指定します。

オプション: -T | --truststorefile truststoreこの値は、TADDM サーバーに接続するための証明書を含むトラストストア・ファイル jssecacerts.cert のロケーションを指定します。このパラメーターは、TADDM へのセキュア接続には必須です。このパラメーターを使用する場合は、-H パラメーターも指定する必要があります。

ジョブをスケジュールするには、次のステップを完了します。

1. Tivoli Workload Scheduler から、TADDM ジョブ定義ファイルを編集ファイルに入力します。テンプレート・ジョブ定義の例を以下に示します。

WORKSTATION_ID#TADDM_JOBSCRIPTNAME "./opt/IBM/taddm/dist/bin/invokejob.sh -u^TADDM_USERNAME^ -p ^TADDM_PASSWORD^ command [parameters]"STREAMLOGON taddmuserTASKTYPE UNIXRECOVERY STOP

^TADDM_USERNAME^ と ^TADDM_PASSWORD^ は、Tivoli WorkloadScheduler で定義する必要がある変数です。この 2 つの変数は、データベースに保管されている値にマップされます。セキュリティー上の理由から、特にパスワードをコーディングする際には、変数を使用して値がオープン・テキストとして表示されないようにしてください。

2. コンポーザーを使用して編集ファイルをデータベースに追加します。

3. ジョブをジョブ・ストリームに追加し、ジョブ・ストリームの実行をスケジュールします。IBM Tivoli Workload Scheduler エージェントは、invokejob.sh スクリプトのアクションを開始してモニターします。

ディスカバリー・ジョブのスケジューリング

以下の例では、スコープ 127.0.0.1 でディスカバリーを実行しています。

dist/bin/invokejob.sh -u USER -p PASSWORD --timeout 60000 discover start--profile "Level 3 Discovery" 127.0.0.1

管理 263

以下の例では、MyScopeSet スコープ・セットでディスカバリーを実行します。この場合、このスコープ・セットが既にスコープ・リストに存在していることが必要です。

dist/bin/invokejob.sh -u USER -p PASSWORD --timeout 60000 discover start--profile "Level 3 Discovery" MyScopeSet

上記の各例では、最後のパラメーターでディスカバリー実行に組み込むスコープ・エレメントまたはスコープ・セットを指定しています。profile パラメーターは必須です。ディスカバリー実行の名前である name パラメーターはオプションです。

以下のコマンドは、現在実行中のディスカバリーを停止する方法を示す例です。

dist/bin/invokejob.sh -u USER -p PASSWORD --timeout 60000 discover stop

discover stop コマンドは、追加の引数を取りません。

ドメイン同期ジョブのスケジューリング

以下の例は、同期サーバー・デプロイメントでドメイン同期を実行する TADDMスクリプト invokejob.sh のコマンド行構文とオプションを示しています。

dist/bin/invokejob.sh -u USER -p PASSWORD --timeout 60000 sync start TestDomain

sync start コマンドと sync stop コマンドはどちらも、同期ジョブを開始または停止するドメインの名前を引数として必要とします。

TADDM と IBM Tivoli Business Service Manager との統合ご使用の IT 環境で行う必要がある特定のタスクに応じて、TADDM と IBMTivoli Business Service Manager 間で使用可能な統合機能を使用できます。これらの機能を使用するには IBM Tivoli Business Service Manager 4.2.1 暫定修正 3 が必要ですが、TADDM の追加構成を行う必要はありません。

ビジネス・アプリケーションのライフ・サイクル状態の更新ライフ・サイクル状態を使用して、TADDM から IBM Tivoli Business ServiceManager に同期するオブジェクトをフィルターに掛けることができます。BusinessServiceLifecycle プログラムを使用して、ビジネス・アプリケーションに関する情報をリストしたり、ビジネス・アプリケーションのライフ・サイクル状態を設定したりすることができます。

IBM Tivoli Business Service Manager ITsystems アプリケーションには、ビジネス・アプリケーションのみが含まれています。そのため、BusinessServiceLifecycle プログラムはビジネス・アプリケーションのみをサポートします。

BusinessServiceLifecycle プログラムは次の場所にあります。

v Linux および UNIX オペレーティング・システムの場合、BusinessServiceLifecycle スクリプトは $COLLATION_HOME/bin ディレクトリーにあります。

v Windows オペレーティング・システムの場合、BusinessServiceLifecycle.bat

バッチ・ファイルは %COLLATION_HOME%¥bin フォルダーにあります。


BusinessServiceLifecycle プログラムは、以下のコマンド行オプションとともに使用します。

BusinessServiceLifecycle -u TADDM_username -p TADDM_password -l | -s guid state

ビジネス・アプリケーションのライフ・サイクル情報をリストするには -l オプションを使用し、ライフ・サイクル状態を設定するには、-s オプションを guid パラメーターおよび state (状態コード) パラメーターと共に使用します。 -l オプションと -s オプションを同時に使用することはできません。

以下の表に、有効な状態コードをリストします。

表 49. 状態コード

コード状態

0 Unknown

1 Other

2 Ordered

3 Received

4 In Test

5 Tested

6 Installed

7 Enabled

8 Disabled

9 Maintenance

10 Retired

11 Archived

12 Accepted

13 Build

14 Development

15 Draft

16 Inventory

17 Offline

18 Postproduction

19 Production

20 Production Ready

21 Sunset

22 Validate

TADDM と Jazz for Service Management との統合TADDM は、Open Services for Lifecycle Collaboration (OSLC) プラットフォームとの統合をサポートしています。OSLC を TADDM と併用することにより、ディスカバリー・データを標準リソース定義の形式で表現することができます。Jazzfor Service Management プラットフォームは、OSLC オープン・コミュニティー仕様に基づいた IBM 統合ツールです。

管理 265

Jazz for Service Management により、すべての Tivoli 製品を、それらに限ることなく、一元的に構成および管理することができます。Jazz for Service Managementは、IT リソース、アプリケーション、およびビジネス相互関係のエンドツーエンド・ビューを表示します。

TADDM OSLC REST 通信TADDM Representational State Transfer (REST) サービスは、いくつかの OSLCREST フィードに渡って OSLC 統合を提供します。このサービスでは、サービスが実行されたときに戻すメディア・タイプを指定し、サービスと関連のあるセキュリティーの側面を記述します。

共通リソース・タイプ・ボキャブラリー (CRTV) は、Tivoli共通データ・モデル(CDM) と共に、TADDM がサポートする IBM および OSLC コミュニティー定義のデータ・モデルです。TADDM で OSLC をサポートすることにより、CDM ディスカバリー・データを CRTV 定義リソースの形式で使用可能にしています。

OSLC REST インターフェース:

REST インターフェースは、TADDM の Open Services Lifecycle Collaboration(OSLC) で使用できます。OSLC REST インターフェースを使用して、登録されている構成アイテム (CI)、それらの属性、および変更履歴に関する情報を取得することができます。

CI の属性に関する情報は、その属性が共通リソース・タイプ・ボキャブラリー(CRTV)、つまり TADDM のボキャブラリーによってサポートされている場合にのみ取得できます。

有効な要求のそれぞれには、具象 CI を識別する GUID が必要です。

以下の 2 つのサービス・タイプがあります。

構成サービスこのサービスは、CRTV リソースの拡張属性を取得するためのインターフェースとなります。

変更履歴サービスこのサービスは、CRTV リソースの一定期間における変更履歴を取得するためのインターフェースとなります。

サービスごとに、次の 3 つのコンテンツ・タイプを表示できます。

v RDF 表現

v OSLC コンパクト・ビュー

v HTML プレビュー

以下の URL が基底アドレスです。

http[s]://taddm_host:port/cdm/oslc/provider_name/ci_guid

ここで

v port は、Tomcat サーバー (TADDM 7.3.0) または WAS Liberty Profile サーバー (TADDM 7.3.0.1 以降) が listen するポートです。デフォルト値は 9430です。


v provider_name は、使用するサービスに応じて決まる以下の 2 つの値のいずれかです。

– configuration

– changehistory

v ci_guid は、TADDM での CI の ID です。

CI の HTML プレビューを表示するには、以下の URL を使用します。

v http[s]://taddm_host:port/cdm/oslc/provider_name/ci_guid/preview

OSLC REST インターフェースは、HTTP-GET 要求のみを受け入れます。 HTTPAccept ヘッダーを使用して、戻されるコンテンツ・タイプを指定できます。

指定された CI の OSLC コンパクト・ビューを表示するには、次の Accept ヘッダーを指定します。

application/x-oslc-compact+xml

指定された CI の RDF 表現を表示するには、次の Accept ヘッダーを指定します。

application/rdf+xml

これは、Accept ヘッダーとして値が指定されない場合のデフォルトの動作です。

OSLC コンパクト・ビュー:

OSLC コンパクト・ビューは、ターゲット・リソースの XML 表現です。

OSLC コンパクト・ビューは、OSLC REST インターフェースによって提供されるプレビューです。ターゲット・リソースのプレビューを表示するには、OSLC 仕様での定義に従ったリソースの表現を提供側が提供する必要があります。

このリソースの表現は、application/x-oslc-compact+xml アクセス・ヘッダーと共にターゲット・リソースの URI に対する HTTP GET 要求を使用することによって取得できます。

提供側は、プレビュー・メカニズムをサポートする場合、利用者がリンクおよびターゲット・リソースのプレビューを表示するために使用可能な情報を含んだコンパクト表現で応答します。

Jazz for Service Management の HTML プレビュー:

Jazz for Service Management のレジストリー・サービスは、登録されたエレメントに関する情報を接続された外部システムから配信するための HTML ユーザー・インターフェースを提供します。

TADDM によって提供されるデータが存在するすべてのエレメントには、HTMLプレビューがあり、選択したエレメント・データの概要を TADDM サーバーから直接に素早く表示することができます。

TADDM は、以下のアドレスで、Jazz for Service Management にフィード・サービスを提供します。

http[s]://host_name:port/cdm/oslc/configuration/guid/preview

管理 267

ここで、host_name および port は TADDM サーバーのホスト名とポート番号、および guid は固有のエレメント ID です。

この URL のページには、選択したエレメントに関する概要が表示されます。このページは、Jazz for Service Management ユーザー・インターフェースに自動的に表示されます。

ページのコンテンツは、TADDM データ管理ポータルに表示される「インベントリー要約の詳細」ビューの「一般」タブのコンテンツに似ています。

セキュリティー:

OSLC REST インターフェースによって提供されるフィードへのアクセスで認証が必要とされるように、TADDM を構成することができます。

REST インターフェースにアクセスするには、以下のいずれかの方法を使用して認証を行う必要があります。

基本 HTTP 認証資格情報を許可要求ヘッダーに含める必要があります。そのヘッダーの値は、基本 HTTP 認証のルールに従う必要があります。

シングル・サインオンシングル・サインオンを使用する場合は、REST インターフェースに対して実行依頼されるすべての要求で、Lightweight Third-Party Authentication(LTPA) トークンを搬送する必要があります。トークンを検証するために、ユーザー・リポジトリーとして WebSphere Virtual Member Manager(VMM) を使用するように、TADDM を構成する必要があります。

VMM の構成について詳しくは、 30 ページの『WebSphere FederatedRepositories を使用する TADDM サーバーの構成』を参照してください。

要求されたフィードが認証なしで表示されるようにするには、collation.propertiesファイルの以下のプロパティーを、有効なレジストリー・サービス URL を使用して構成する必要があります。

com.ibm.cdb.topobuilder.integration.oslc.frsurl

そうすれば、有効な資格情報が要求に含まれていない場合には、事前構成済みのユーザー名とパスワードが使用されます。

ユーザー名とパスワードは、共通データ・モデル Web アプリケーションのweb.xml デプロイメント記述子ファイルから取得されます。このカスタマイズは、以下の OSLCFilter init パラメーターを使用して構成できます。

OSLC_LOGIN_OFFこのパラメーターを true に設定すると、着信要求に独自の有効な資格情報が含まれていない場合に、OSLC_USER および OSLC_PASSWORD パラメーターによって指定されたユーザー名とパスワードが使用されます。

このパラメーターを false に設定する場合は、着信要求に有効な資格情報を含める必要があります。デフォルト値は true です。


OSLC_USERこのパラメーターには、有効な資格情報が要求に含まれていない場合に使用するユーザー名を設定します。必要に応じて、使用されるユーザー名を変更できます。

デフォルト値は administrator です。

OSLC_PASSWORDこのパラメーターには、有効な資格情報が要求に含まれていない場合に使用するパスワードを設定します。TADDM UI を使用して administrator のパスワードを変更する場合は、このパラメーターによって設定されるパスワード値を更新する必要があります。

デフォルト値は collation です。

OSLCAgent を使用したレジストリー・サービスへのデータのエクスポートOSLCAgent トポロジー・エージェントを使用して、構成アイテム (CI) 情報をレジストリー・サービスにエクスポートすることができます。

OSLCAgent は、TADDM からレジストリー・サービスにデータをエクスポートするための自動化ソリューションです。このエージェントは、定期的に以下のタスクを実行します。

v レジストリー・サービスに登録可能なオブジェクトがないかどうか照会する

v それらのオブジェクトを RDF 形式のメッセージに変換する

v それらのメッセージを HTTP を使用して送信する

OSLCAgent は統合グループに属しています。実行と次の実行の時間間隔は、collation.properties ファイルの次のエントリーで指定します。

com.ibm.cdb.topobuilder.groupinterval.integration

OSLCAgent は、構成プロバイダーおよび変更履歴プロバイダーとして機能します。これら 2 つの役割は、別々に使用可能にすることができます。構成プロバイダーとしての役割を使用可能にするには、以下のプロパティーを true に設定します。

com.ibm.cdb.topobuilder.integration.oslc.enable.configurationsp

変更履歴プロバイダーとしての役割を使用可能にするには、以下のプロパティーをtrue に設定します。

com.ibm.cdb.topobuilder.integration.oslc.enable.changehistorysp

レジストリー・サービスに接続するように OSLCAgent を構成するには、レジストリー・サービス・アドレスとアクセス・エントリーの詳細を指定する必要があります。

レジストリー・サービス・アドレスは、以下のプロパティーで構成します。

com.ibm.cdb.topobuilder.integration.oslc.frsurl

レジストリー・サービス・アドレスは以下のフォーマットで指定します。

protocol://fqdn_or_ip_or_hostname:port

管理 269

例: http://192.0.2.24:9081

注: 他の製品との整合性を確保し、統合の問題を避けるために、IP アドレスよりも完全修飾ドメイン名 (FQDN) または完全修飾ホスト名が推奨されます。ただし、TADDM と共に使用する他のすべての製品で IP アドレスが使用されている場合は、IP アドレスを指定する必要があります。 TADDM と共に使用している製品がない場合でも、後で他の製品を追加する場合のために FQDN を使用することが推奨されます。

統合/レジストリー・サービス・タイプのアクセス・リスト・エントリーを作成します。レジストリー・サービスのユーザー名とパスワードを指定します。

OSLCAgent の動作は、以下のプロパティーを使用して細かく調整することができます。

com.ibm.cdb.topobuilder.integration.oslc.maxtimeperrunこのプロパティーは、OSLCAgent が実行されるのを許可する最大時間 (分)を指定します。この時間は、タイムアウト・イベントの前に実行依頼されてプールに入れられるジョブによって消費される時間だけ、プロバイダーごとに長くすることができます。このプロパティーを構成しない場合、または-1 に設定した場合は、OSLCAgent の 1 回の実行に許容される時間は無制限になります。

com.ibm.cdb.topobuilder.integration.oslc.jobspoolsizeこのプロパティーは、同時に実行することを許可するジョブの最大数を指定します。各ジョブは単一の CI を登録します。このプロパティーを構成しない場合、デフォルト値は 10 となります。

com.ibm.cdb.topobuilder.integration.oslc.frshttptimeoutこのプロパティーは、HTTP 接続のタイムアウトをミリ秒単位で指定します。デフォルト値は 5000 です。

com.ibm.cdb.topobuilder.integration.oslc.frsfailfastafterこのプロパティーは、HTTP 接続タイムアウトの連続回数を指定します。この回数に達した後は、エージェントはレジストリー・サービスが使用不可であると見なし、接続の試行を停止します。デフォルト値は 5 です。

com.ibm.cdb.topobuilder.integration.oslc.unregisterableIPsこのプロパティーは、公開 IP アドレスではなく、リソース・レコードのオーバー・マージの原因になる可能性があるために、登録してはならない IPアドレスを指定します。このプロパティーには、正規表現を含めることができます。デフォルト値は、127.0.0.1,01111111000000000000000000000001,0:0:0:0:0:0:0:1,

0000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000

000000000001 です。

com.ibm.cdb.topobuilder.integration.oslc.unregisterableFQDNsこのプロパティーは、公開ドメイン名ではなく、リソース・レコードのオーバー・マージの原因になる可能性があるために、登録してはならない完全修飾ドメイン名を指定します。このプロパティーには、正規表現を含めることができます。デフォルト値は、localhost.localdomain,localhost,loopback6(.?¥u005c¥w*)* です。


com.ibm.cdb.topobuilder.integration.oslc.enablecrtvtype.CRTVTypeこのプロパティーは、OSLCAgent で特定の共通リソース・タイプ・ボキャブラリー (CRTV) タイプの CI のみを処理するよう指定します。使用可能にすると、その CRTV タイプの CI のみが、登録、更新、および登録解除されます。

例えば、次のように設定するとします。

com.ibm.cdb.topobuilder.integration.oslc.enablecrtvtype.ComputerSystem=true

この場合は、コンピューター・システムのみが処理されるように指定されます。

以下の CRTV タイプが許可されます。

v ComputerSystem

v データベース

v Fix Pack 2 SAPSystem

v ServiceInstance

v SoftwareModule

v SoftwareServer

com.ibm.cdb.topobuilder.integration.oslc.history.days_previousこのプロパティーは、ランチ・イン・コンテキスト (LIC) URL を使用して使用可能な変更履歴情報の日数を指定します。デフォルト値は 5 です。

days_previous プロパティーを使用すると、変更履歴情報の管理に必要なストレージ・スペースの量と処理時間を制御できます。

LIC URL は、「OSLC 変更履歴 HTML (OSLC Change HistoryHTML)」プレビューにリストされます。

この値が 0 より大きい場合は、days_previous パラメーターが LIC URLに適用され、表示される変更履歴の量が制限されます。

この値が 0 以下の場合は、days_previous パラメーターが LIC URL に含まれず、その CI の変更履歴全体を表示できます。

OSLCAgent のコマンド行インターフェースOSLCAgent コマンド行インターフェース (CLI) を使用して、構成アイテム (CI)情報をレジストリー・サービスに手動でエクスポートすることができます。

OSLCAgent の場合、コマンドとスイッチの組み合わせを runtopobuild スクリプトまたはバッチ・ファイルに渡すことができます。個々のコマンドおよびスイッチには、短い 1 文字の形式と、より長い記述的な形式があります。コマンドとスイッチの形式は任意の組み合わせで使用することができます。

使用可能なコマンドは次のとおりです。

v -R | –refreshAll true|false

このコマンドは、既に登録済みのものも含め、すべての適格 CI を登録します。

v -r | -refreshGuid guid

管理 271

このコマンドは、既に登録済みのものも含め、指定された GUID を持つ CI を登録します。

v -l | -refreshIgnored true|false

十分な深さがない位置で CI がディスカバーされた場合は、CI の命名規則が正しく指定されていない可能性があります。デフォルトでは、このような CI はOSLCAgent によって無視されます。このコマンドは、こうした CI をもう一度処理するように、OSLCAgent に対して指示を出します。

特定のアクションを指定するには、任意のコマンドを使用してスイッチを渡すことができます。使用できるスイッチには 2 つのタイプがあります。

特定の CRTV タイプの処理を使用可能または使用不可にするには、以下のスイッチを使用できます。

v -c | --enableComputerSystem true|false

v -d | --enableDatabase true|false

v -i | --enableServiceInstance true|false

v -m | --enableSoftwareModule true|false

v -s | --enableSoftwareServer true|false

例えば、コンピューター・システムを再登録しない場合は、-c false スイッチを使用します。

構成および変更履歴の役割を使用可能または使用不可にするには、以下のスイッチを使用できます。

v -h | --enableChangeHistoryProvider true|false

v -p | --enableConfigurationProvider true|false

例えば、変更履歴プロバイダーとしての再登録を実行しない場合は、-h false スイッチを使用します。

runtopobuild スクリプトまたはバッチ・ファイルの実行時にコマンドまたはスイッチを渡さなかった場合にデフォルト値が使用されるようにするには、collation.properties ファイル内に以下のプロパティーを構成します。

v com.ibm.cdb.topobuilder.integration.oslc.refreshAll=true|false

v com.ibm.cdb.topobuilder.integration.oslc.refreshGuid=guid

v com.ibm.cdb.topobuilder.integration.oslc.enablecrtvtype.crtv_type

使用可能なパラメーターとスイッチの完全なリストについては、$COLLATION_HOME/support/bin に移動し、-H スイッチを指定して runtopobuild スクリプトまたはバッチ・ファイルを実行してください。以下に例を示します。

./runtopobuild.sh -H

レジストリー・サービスへの構成アイテムの登録このトピックでは、TADDM によってディスカバーされ、レジストリー・サービスに登録されているかどうかが照会される構成アイテム (CI) のリストと、設定対象の属性のリストを、詳細なマッピング情報とともに記載します。


特定の CI が登録されていない場合、すべての登録スレッドでは、その CI が登録されていない理由に関するログ情報が生成されます。ログには、設定解除された命名規則属性のリストが記録されます。正しいロギング・レベルを構成するには、collation.properties ファイルで次のプロパティー値を設定します。

com.collation.log.level.vm.Topology=DEBUG

以下は、すべての CRTV タイプに共通の属性です。

guid CI の GUID 値が設定されます。

name name、label、または displayName 属性の値が設定されます。

descriptiondescription 属性の値が設定されます。

lastDiscoveredTimelastModifiedTime 属性の値が設定されます。

SoftwareServer

CRTV SoftwareServer タイプには、以下の TADDM クラスと属性が含まれています。

v WebSphereServer

– host

– node

– node.cell

v Db2Instance

– home

– host

v MQQueueManager

– displayName | label | name

v AppServer


– host

v CommunityServer

– displayName | label

v SametimeServer


v MeetingServer


v SpecialityServer


v AgentManager


v SharePointRole


管理 273

TADDM 属性は、CRTV 属性に以下のようにマップされます。

TADDM 属性 CRTV 属性その他の情報

PrimarySAP crtv:serverAccessPoint serviceAccessPoint リソースは、crtv:ipAddress を使用して、そのリソースが指すIpAddress リソースと共に登録されます。

version crtv:version

vendorName crtv:manufacturer

host crtv:runsOn crtv:runsOn はComputerSystem を指します

home crtv:instancePath DatabaseServer とDb2Instance の場合のみ。

dataPath crtv:instancePath MQQueueManager の場合のみ。

rdf:type は、以下のいずれかの値に設定されます。

v J2EEServer

v WebSphereServer

v IBMHTTPServer

v WebServer

v Db2Instance

v OracleInstance

v MQQueueManager

v WebServer

v DatabaseInstance

v CICSRegion

ComputerSystem

CRTV ComputerSystem タイプには、以下の TADDM クラスと属性が含まれています。

v ComptuerSystem

以下の属性の組み合わせのいずれかが設定されます。

– systemId &VMID

– systemId

– serialNumber & model & manufacturer &VMID

– serialNumber & model & manufacturer

– systemBoardUUID

– ipInterfaces




label または displayName crtv:name

OSVersion またはOSRunning

crtv:version

hostSystem crtv:dependsOn

fqdn crtv:fqdn

name crtv:shortHostname name が設定されており、それが有効なホスト名である場合。

SunSPARCComputerSystemの場合のみ。

ipInterface crtv:ipAddress それらの IP アドレスのすべての FQDN は crtv:fqdn にマージされます。

crtv:type には以下のいずれかの値が設定されます

v Generic

v SunFire

v SunSPARC

v SystemP

v Unitary

v Virtual

v WPAR

LinuxUnitaryComputerSystem の場合は、追加の属性が以下のようにマップされます。


manufacturer crtv:manufacturer

model crtv:model

serialNumber crtv:serialNumber

VMID crtv:vmid CPUType と Model が設定されている場合:

v Intel の場合、VMID はnull に設定され、crtv:systemBoardUUID にsystemBoardUUID またはconvertedUUID を設定しようと試みられます。

v power の場合、CS はVMID が設定されている場合には無視されます。

SunSPARCUnitaryComputerSystem の場合は、追加の属性が以下のようにマップされます。

管理 275


systemId crtv:hostid

VMID crtv:vmid

その他のコンピューター・システムの場合、追加の属性が以下のようにマップされます。


manufacturer crtv:manufacturer

model crtv:model

serialNumber crtv:serialNumber

VMID crtv:VMID OSRunning がWindowsOperatingSystem に設定されている場合、VMIDは null に設定されます。

OSRunning が HpUx に設定されている場合、VMID、model、およびserialNumber は null に設定されます。

systemBoardUUID またはconvertedUUID

crtv:systemBoardUUID

worldWideName crtv:hostid FCSwitch、TapeLibrary、および TapeMediaChanger 場合のみ。

データベース

CRTV Database タイプには、以下の TADDM クラスと属性が含まれています。

v Db2Database

– name | displayName

v IDSDatabase


v IMSDatabase


v OracleDatabase


v SqlServerDatabase


v SybaseDatabase


v DominoDatabase





name crtv:name

fileName crtv:name DominoDatabase の場合のみ。

parent crtv:dbInstance

ServiceInstance

以前のバージョンとの互換性が確保されているかどうかに応じて、CRTVServiceInstance タイプには、以下の TADDM クラスおよび属性が含まれています。

v 以前のバージョンとの互換性が確保されている場合:

– BusinessSystem

- name

– アプリケーション

- name

– ServiceInstance

- name

– ServiceInfrastructure

- name

– SAPSystem

- SAPSystemSID | systemHome

v 以前のバージョンとの互換性が確保されていない場合:

– CustomCollection (「BusinessApplication」タイプのみ)

- collectionId



name crtv:name

SAPSystemSID:systemHome crtv:name name と displayName のどちらも設定されていない場合。

SAPSystem の場合のみ。

parentGUID または NULL crtv:parentServiceInstance

collectionId crtv:name

SoftwareModule

CRTV SoftwareModule タイプには、以下の TADDM クラスと属性が含まれています。

v SoftwareModule

管理 277

– fileName

– name

– parent.name

v MQQueue

– name

– queueManager



parent deployedTo

fileName crtv:fileName

rdf:type は、以下のいずれかの値に設定されます

v J2EEApplication

v MQQueue

OSLC のトラブルシューティングこのトピックでは、OSLC で発生する一般的な問題について説明し、それらの問題の解決方法を紹介します。

構成された TADDM URL にポート番号が含まれていない

問題 collation.properties ファイルで構成する TADDM URL プロパティーtaddmURL には、ポート番号を含める必要があります。

このプロパティーにポート番号が含まれていない場合は、TADDM URL を更新してポート番号を含め、レジストリー・サービス (特定のプロバイダー)に関する情報をクリアしてから、TADDM のタイム・スタンプをクリアする必要があります。

解決方法

TADDM URL を更新してポート番号を含めるには、以下の手順を実行します。

1. collation.properties ファイルで、taddmURL プロパティーを次のように設定します。

taddmURL=http://server.domain:port

2. レジストリー・サービスが実行されているコンピューターで、以下の手順を実行します。

a. /opt/IBM/JazzSM/registry/etc に移動します。

b. CLI.properties ファイルで、以下のプロパティーの資格情報を構成します。

v ds.jdbc.user

v ds.jdbc.password

v appserver.user

v appserver.password

c. /opt/IBM/WebSphere/AppServer/bin に移動します。


d. stopServer.sh スクリプトを実行して WebSphere ApplicationServer を停止します。

./stopServer.sh server_name -user user_name -p password


./stopServer.sh server1 -user wasadmin -p passw0rd

e. /opt/IBM/JazzSM/registry/bin に移動します。

f. 適切なパラメーターを指定して frs.sh スクリプトを実行します。

./frs.sh uninstall -type db -properties ../etc/CLI.properties

g. データベースが除去されたことを確認します。そうなっていない場合は、次のコマンドを実行します。

db2 drop db db_name

db2 create db db_name

ここで、db_name はレジストリー・サービス・データベースの名前です。

h. /opt/IBM/JazzSM/registry/bin に移動します。

i. 適切なパラメーターを指定して frs.sh スクリプトを実行します。

./frs.sh install -type db -properties ../etc/CLI.properties

j. /opt/IBM/WebSphere/AppServer/bin に移動します。

k. startServer.sh スクリプトを実行して WebSphere ApplicationServer を始動します。

./startServer.sh server_name -user user_name -p password


./startServer.sh server1 -user wasadmin -p passw0rd

l. 適切なパラメーターを指定して frs.sh スクリプトを実行します。

./frs.sh uninstall -type container -properties ../etc/CLI.properties

m. 適切なパラメーターを指定して frs.sh スクリプトを実行します。

./frs.sh install -type container -properties ../etc/CLI.properties

以下のコマンドを使用することにより、特定のプロバイダーのレジストリー・サービスから項目を除去することができる場合があります。

./frs.sh deleteProvider -providerUrl url -properties cli.properties

3. TADDM データベースが稼働しているコンピューターで、以下の手順を実行します。

a. $COLLATION_HOME/support/bin に移動します。

b. 以下の例に示すように、適切なパラメーターを指定してruntopobuild スクリプトまたはバッチ・ファイルを実行します。

./runtopobuild.sh -a OSLCAgent -R

Tivoli Directory IntegratorIBM Tivoli Application Dependency Discovery Manager (TADDM) を購入すると、 TADDM と他のデータ・ソースとの統合を可能にする Tivoli DirectoryIntegrator も提供されます。

管理 279

Knowledge Center の Tivoli Directory Integrator の資料http://www-01.ibm.com/support/knowledgecenter/SSCQGF_7.1.0/KC_ditamaps/welcome.html?lang=en

Tivoli Application Dependency Discovery Manager Wiki の TADDM 統合シナリオ

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/Integration%20Scenarios

以前のバージョンとのビジネス・エンティティーの互換性DataApi を使用して TADDM からデータを読み取る製品または SQL を使用してTADDM データベースから直接データを読み取る製品と TADDM 間の統合を可能にする新機能が導入されました。このような製品の例としては、IBM TivoliBusiness Service Manager (TBSM)、IBM SmartCloud Control Desk(SCCD)、Tivoli Directory Integrator (TDI) があります。現在の BusinessApplication データ・モデルは、CustomCollection インターフェースに依存しています。このインターフェースと、以前の Application および ITSystem インターフェースには共通点はありません。この新機能により、システムを変更せずに他の製品との統合を行うことが可能になります。

将来のバージョンの TBSM および SCCD では、新機能を備えた BusinessApplication モデルが導入されます。その目的は、カスタム・コレクション・インスタンスのコピーである以前のビジネス・エンティティーを生成することです。

この新機能は、以前のバージョンとの互換性を維持するためのものですあり、以下の機能から構成されています。

BizAppsAgent を実行している間の追加ステップこの追加ステップにより、エージェントで生成される各カスタム・コレクションの以前のバージョンと互換性のあるビジネス・エンティティー (サービス、アプリケーション、コレクション) が生成されます。

このステップをアクティブにするために、com.ibm.cdb.serviceinfrastructure.earlier.ver.compatibility という新しいプロパティーが collation.properties ファイルに追加されました。このプロパティーのデフォルト値は、アップグレード・シナリオの場合はTRUE、フレッシュ・インストール・シナリオの場合は FALSE です。

OSLC のサポートOSLC エージェントが変更され、古いビジネス・エンティティーまたは新しいカスタム・コレクションを登録できるようになりました。互換性フラグにTRUE が設定されている場合は、古いビジネス・エンティティーが登録されます。その以外の場合は、Jazz for Service Management (JazzSM) のコンテンツを作成するためにカスタム・コレクションが使用されます。

将来は、統合する製品が新しいモデル・オブジェクト (カスタム・コレクションおよびノード) を使用してデータのロードを開始するときに、ビジネス・エンティティーを完全に再ロードすることが必要になります。古いビジネス・アプリケーション (アプリケーション) と新しいビジネス・アプリケーション (カスタム・コレクシ


http://www-01.ibm.com/support/knowledgecenter/SSCQGF_7.1.0/KC_ditamaps/welcome.html?lang=en

http://www-01.ibm.com/support/knowledgecenter/SSCQGF_7.1.0/KC_ditamaps/welcome.html?lang=en




ョン) の GUID を同じにすることはできません。重複を避けるには、新しいカスタム・コレクションをロードする前に、古いビジネス・アプリケーションを削除する必要があります。

機能グループの作成

古いビジネス・アプリケーションとは異なり、新しいビジネス・アプリケーションには、機能グループがありません。ただし、同様の目的に対応した新しい層の機能が導入されました。以前のバージョンとの互換性を維持するために、層名に対応した名前を持つ機能グループが固有の層ごとに作成されます。

詳しくは、TADDM の「ユーザーズ・ガイド」の『ビジネス・アプリケーション層』トピックを参照してください。

BigFix の統合Fix Pack 5

IBM は、TADDM でアンカーやゲートウェイを使用せずにセキュアなサーバー/マシンを検出するためのサポートの構築に取り組んできました。このサポートは、BigFix インフラストラクチャーの利用をベースにしています。

注: パスが相対パスとして示されている場合は、$COLLATION_HOME

(/opt/ibm/taddm/dist) または %COLLATION_HOME% (E:¥ibm¥taddm¥dist) の相対パスであることを前提としています。

概要IBM/Aricent では、TADDM でアンカーやゲートウェイを使用せずにセキュアなサーバー/マシンを検出するためのサポートの構築に取り組んできました。このサポートは、BigFix インフラストラクチャーの利用をベースにしています。

注: パスが相対パスとして示されている場合は、$COLLATION_HOME

(/opt/ibm/taddm/dist) または %COLLATION_HOME% (E:¥ibm¥taddm¥dist) の相対パスであることを前提としています。

目的:

TADDM はアンカーとゲートウェイを使用して、ファイアウォールの背後にあるマシン/アプリケーション/ネットワークをディスカバーします。現在、IBM NetcoolMonitoring ツール (ITM) を使用すると、アンカー/ゲートウェイの使用を回避できます。または、TADDM の BigFix アーキテクチャーとの統合を使用して、アンカーとゲートウェイを使用しないようにすることもできます。BigFix アーキテクチャーは、BigFix サーバー (BES サーバー ) と複数の BigFix エンドポイント (BES クライアント) で構成されます。ここで、BES クライアントは、BES サーバー経由でアクセス可能なセキュア・マシンです。BES サーバーを介して BES クライアントで TADDM スクリプト・パッケージを自動的に実行するために、BigFix インフラストラクチャーを再使用/利用できます。

TADDM 管理者に対するこの統合の主な利点は以下のとおりです。

1. アンカーなしでファイアウォール・ゾーンをディスカバーできます。

管理 281

2. BigFix アーキテクチャー (オープン・セキュア・ポートなど) を再使用してエンドポイントにアクセスできます。また、標準の TADDM 方式を使用して同じターゲットをディスカバーするためのセットアップ時間を節約できます。

3. TADDM スクリプト・ベース・センサーの戦略的な方向と一致するように調整します。

4. 必要とされる TADDM 管理者の介入が最小になります。

5. TADDM - ITM 統合を使用しないでファイアウォール・ゾーン・マシンのディスカバリーを行うための代替方式が提供されます。

参照資料:

TADDM の資料

TADDM を統合できる製品の、サポートされるバージョンを以下の表に示します。

TADDM と統合する製品について詳しくは、各製品の資料を参照してください。

v TADDM 7.3 およびセンサーの Knowledge Center (公式資料)http://www-01.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/welcome_page/kc_welcome-444.html?lang=en

v TADDM 7.3 センサーおよびサポートされるターゲット・システムhttps://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d5ebce8-2dd8-449c-a58e-4676134e3eb8#fullpageWidgetId=Wea1cb2531f10_4ccd_99d7_6ab0334cb21f&file=e70bf323-31f1-45ba-8992-4cb491feab4a

v TADDM 非同期スクリプト・ディスカバリー (ASD) の構成https://www.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_async_script_sensors.html#sensorsthatcanbescripted

v IBM BigFix 構成ガイド https://www.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_async_script_sensors.html#sensorsthatcanbescripted

v TADDM サポート Web サイト http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html

v TADDM Wiki https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/Home これは、TADDM の最新の情報とベスト・プラクティスに関する優れた情報源です。このページにブックマークを付け、適宜参照してください。

v TADDM フォーラム http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1547&categoryID=15&ca=drs-fo

v Request for Enhancement Community http://www.ibm.com/developerworks/rfe/?BRAND_ID=90 このコミュニティーは、製品に対する機能強化を IBM 開発者に直接要求する場合に使用してください。


http://www-01.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/welcome_page/kc_welcome-444.html?lang=en

http://www-01.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/welcome_page/kc_welcome-444.html?lang=en

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d5ebce8-2dd8-449c-a58e-4676134e3eb8#fullpageWidgetId=Wea1cb2531f10_4ccd_99d7_6ab0334cb21f&file=e70bf323-31f1-45ba-8992-4cb491feab4a




https://www.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_async_script_sensors.html#sensorsthatcanbescripted






http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliApplicationDependencyDiscoveryManager.html

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Application%20Dependency%20Discovery%20Manager/page/Home



http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1547&categoryID=15&ca=drs-fo

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1547&categoryID=15&ca=drs-fo

http://www.ibm.com/developerworks/rfe/?BRAND_ID=90

http://www.ibm.com/developerworks/rfe/?BRAND_ID=90

ソリューション・アーキテクチャー:

TADDM - BigFix 統合は、TADDM 管理者の手動による介入が必要な非同期スクリプト・ディスカバリー (ASD) の現在の動作を拡張および自動化することに基づいています。この統合は、TADDM スクリプト・パッケージを介してディスカバリーを実行するために、BigFix インフラストラクチャーがファイアウォール・ゾーン・マシンに提供する接続を使用します。

ASD では、TADDM 管理者は以下のステップを手動で実行する必要があります。

1. TADDM サーバーで、ターゲットで実行されるすべてのセンサーを含むディスカバリー・パッケージを作成するスクリプトを実行します。

2. このパッケージをターゲット・システムに転送します。

3. ターゲット・システムでディスカバリー・パッケージを実行します。

4. ターゲット・システムで生成された結果ファイルを TADDM サーバーに転送します。

現在のソリューションでは、手動でのステップが自動化されているため、このソリューションは自動化非同期スクリプト・ディスカバリー (AASD) とも呼ばれます。TADDM 管理者は、TADDM サーバーでディスカバリーを開始するスクリプトを実行するだけで、残りのステップは自動的に実行されます。

BigFix ディスカバリーのステップ:

BigFix ディスカバリーのステップ詳細

ステップ 1: BigFix 統合スクリプト

TADDM ディスカバリー・サーバーから AutoASD ディスカバリー (AASD) を開始するスクリプト「runBigFixDiscovery.sh」が開発されました。このスクリプトはオンデマンドで実行できます。このスクリプトは、(BigFix アクセス資格情報に加えて) ディスカバリー・スコープとディスカバリー・プロファイル名を入力として受け取り、以下のモードをサポートします。

v ディスカバー・モード - BigFix ディスカバリーを開始する場合

v ポーリング・モード – BigFix ディスカバリーの結果をポーリングする場合

v クリーンアップ・モード - BES ルート・サーバーからディスカバリー結果パッケージをオンデマンドでパージする場合

v 再ディスカバー・モード - 以前のディスカバリーを再実行する場合

a) AutoASD センサー・パッケージの作成

v 指定されたディスカバリー・プロファイルがセンサーのリストをフェッチするために使用され、有効なスクリプト・センサーのサブセットのみが AASD スクリプト・パッケージの作成において考慮されます。TADDM がサポートするすべてのスクリプト・センサーの詳細なリストについては、付録 D を参照してください。なお、この機能は、標準の ASD モードでサポートされているこれらのセンサーのサブセットのみをサポートすることに注意してください。

v ディスカバリー・プロファイルの他の非スクリプト・センサーは無視されます。

管理 283

v AASD パッケージは OS に依存しません。結果として、一部のセンサーがBigFix エンドポイントで失敗する場合があります (存在しない場合)。

v 生成された AASD スクリプト・パッケージは、/api/upload REST API を使用して BigFix ルート・サーバーにアップロードされます。

b) BigFix タスクの作成

v 指定されたディスカバリー・スコープを使用して、BigFix が理解する「関連性」XML が作成されます。

v 「関連性」とダミー「ActionScript」を使用して BigFix タスク XML が生成されます。

v 現在の日時に基づいてタスク・タイトルを生成します。

v /api/tasks/custom/TADDM REST API を使用して、BigFix サーバーでカスタム・サイト、つまり「TADDM」の下に BigFix タスクを作成します。

c) BigFix タスクの開始

v <SourcedFixletAction> を使用して、上記で作成した BigFix タスクのアクション実行を開始します。

v /api/actions BigFix REST API を使用して、ターゲット・エンドポイントで「ActionScript」実行を開始します。

ステップ 2: スクリプトの実行

v 「ActionScript」実行の一環として、TADDM AASD パッケージが解凍され、含まれていた (ディスカバリー・プロファイルに基づく) センサー・スクリプトがBigFix エンドポイントで実行されます。

ステップ 3: zip の収集

v 「ActionScript」実行が終了すると、TADDM AASD パッケージの実行からBES クライアントで生成された結果パッケージが BES ルート・サーバーにコピーされます。

ステップ 4: TADDM への結果のインポート

v TADDM は、継続的に BigFix サーバーの DB をポーリングして、BES サーバーにアップロードされた結果ファイルの有無を確認します。

v 新しい結果ファイルが存在することが DB で示された場合、TADDM は HTTP要求を行い、暗号化された結果ファイルをフェッチし、復号し、保存します。

v その後、TADDM は、構成済みのスコープとプロファイルに基づいてこれらの結果ファイルを処理し、ディスカバーされたオブジェクトをデータベースに保管します。

TADDM - Bigfix 統合 (限定利用版)BigFix 拡張 TADDM ディスカバリー・ソリューションの限定利用版のリリースでは、Windows、Linux、AIX、Solaris OS と関連センサー (複数エンドポイントの場合) のエンドツーエンドの機能実行に重点を置いています。また、BigFix REST APIによる TADDM と BigFix 間の SSL 通信がサポートされます。ディスカバリーはTADDM ディスカバリー・サーバーから開始でき、自動取得されたディスカバリー結果を TADDM GUI で表示できます。


前提事項:

ディスカバリーを実行する上で、以下の前提事項が考慮されています。

1. BigFix サーバーとクライアントのバージョンが、セクション 2.1 で挙げたものである。

2. BigFix クライアントに、BigFix サーバーがアップロードしたディスカバリー・タスク/アクション・スクリプトを実行するための適切な権限がある。

3. collation.properties に構成された BigFix SQL データベース・ユーザーに、BFEnterprise データベースに対する読み取りアクセス権が必要である。

4. BigFix エージェント経由で実行されるセンサー・スクリプト・パッケージに、設定された一時ディレクトリー (例:「C:¥Windows¥Temp」) への書き込み権限が必要である。一時ディレクトリーは collation.properties で設定でき、ディレクトリー・パスにスペースが含まれないことを前提とする。

5. スクリプト要求パッケージのクリーンアップは TADDM ディスカバリー・サーバーでは処理されないため、管理者による管理が前提となる。

6. TADDM-BigFix 統合は TADDM に現在存在する ASD フレームワークに基づく。そのため、この統合のパフォーマンス特性は ASD フレームワークのベンチマークに基づく。

7. TADDM ディスカバリー・サーバーでの BigFix Discovery スクリプトの実行には「taddmusr」のみ使用でき、root ユーザーは許可されない。

8. Bigfix ルート・サーバーのクリーンアップ - クリーンアップは TADDM を始動するたびに呼び出される。また、設定された期間(com.collation.bigfix.root.cleanup.interval = デフォルトは 1 日) に従って定期的にも呼び出される。これにより、設定された時間(com.collation.bigfix.root.cleanup.days = デフォルトは 5 日) より古い結果ファイルが削除される。

9. TADDM サーバーのクリーンアップ - ディスカバリー時に TADDM サーバーに作成/コピーされたすべての結果ファイルと、「taddmasd」が含まれ「_DONE」で終わる名前のファイルのクリーンアップが処理される。(TADDM サーバーでのクリーンアップを可能にするには、付録 A の 6 つ目の黒丸に記載されているしきい値が少なくとも 1 つ設定されている必要があります)。

10. エンドポイントのクリーンアップ – ディスカバリー・エンドポイントのクリーンアップはデフォルトで有効になっており、以下のプロパティー設定を構成することで制御できる。

v a) 「com.collation.bigfix.endpoint.cleanup」の値を「N」に設定すると、ディスカバリー・エンドポイントでのクリーンアップが無効になります。

前提条件:

TADDM サーバーからのディスカバリーを開始する前に、以下の前提条件が満たされている必要があります。

管理 285

1. ディスカバリー・プロファイルの作成中に、強制的にASDSensor、ASDPingSensor、汎用サーバー・センサーを選択し、かつPingSensor、PortSensor、SessionSensor のチェック・マークを外すこと。

2. セクション 2.3 に指定されたすべての構成ステップが完了していること。

3. Bigfix アクション・スクリプトで、Windows エンドポイントの場合はネイティブの powershell コマンドを使用して要求パッケージが unzip 済みであり、Linuxエンドポイントの場合はネイティブの tar コマンドを使用して要求パッケージが解凍済みであること。

注: 特定の要件に基づいて、ActionScript をカスタマイズできます。このカスタマイズは、$COLLATION_HOME/etc/ folder にあるお客様が変更可能なActionScript_Pre_Post.txt ファイルを更新することによってサポートされます。例えば、カスタム unzip ソフトウェア (BigFix ルート・サーバーに配置された実行可能ファイルの配布) のダウンロードや使用を有効にできます。サンプルのスニペットの例を以下に示します。

%WIN_PRE_START%if {not exists file "C:¥Windows¥System32¥unzip.exe"}prefetch unzip.exe sha1:e1652b058195db3f5f754b7ab430652ae04a50b8size:167936 http://10.160.161.199:52311/Uploads/Unzip/unzip.exe

// Make sure that environment is set appropriately and "unzip"utility is available in the windows PATHcopy "__Download¥unzip.exe" "C:¥Windows¥System32¥unzip.exe"

endif%WIN_PRE_END%

%WIN_POST_START%%WIN_POST_END%

%LIN_PRE_START%%LIN_PRE_END%...

4. ディスカバリーを実行しているユーザーに、結果フォルダーに対する読み取り/書き込み権限が付与されていること。

5. TADDM サーバー、BigFix ルート・サーバー、およびディスカバリー・ターゲットで処理される要求パッケージと結果パッケージに対応するために、十分なディスク・スペース、処理能力、およびメモリーが使用可能であること。

6. BigFix ルート・サーバーに対する正常な結果アップロードを可能にするために、「_BESClient_ArchiveManager_MaxArchiveSize」設定に十分な値が指定されてBigfix エージェント (エンドポイント・コンピューター) が構成されていること。

7. 正しいスコープとプロファイルが設定されていること (スコープとプロファイルの設定については、セクション 4.1 を参照してください)。

8. BigFix サーバー上でサイト名「TADDM」が構成されており、存在していること。

9. BigFix ディスカバリーの場合にも、標準の ASD センサー・スクリプトに必要なすべての前提条件が適用される。


v a) Windows2003 エンドポイントが関与するディスカバリーの場合は、Powershell 実行可能ファイルをインストールして正しく構成する必要があります。

制限:

現行リリースには、以下の制限が設けられています。

1. ディスカバリー中に指定され、BigFix ルート・サーバーから到達できないディスカバリー・ターゲットは、ディスカバリー履歴に表示されません。

2. PingSensor、PortSensor、および SessionSensor は、他のセンサーが選択されるか有効になった際に自動的に有効になり、ディスカバリー・プロファイルの作成時に手動で無効にする必要があります。

3. TADDM ディスカバリー・サーバー/BigFix ルート・サーバーでの要求パッケージのクリーンアップは、設計によりサポートされていません。再ディスカバリー(再ディスカバリー・モードによってトリガーされます) 時に使用される可能性があることを考慮しています。

4. 再ディスカバリーは、元のディスカバリーが開始されたのと同じ TADDM ディスカバリー・サーバーからのみサポートされます

5. これは限定利用版のリリースであるため、翻訳、オンライン資料のサポートなどは利用できません。

6. BigFix 統合では、カスタム・サーバー・ディスカバリーはサポートされていません

構成:

このセクションで説明されているステップに従い、任意の構成を設定します。

Bigfix Discovery の基本構成:

1. $COLLATION_HOME/etc/collation.properties にある以下の必須プロパティーを設定します。

a) BigFix 統合機能の設定

com.collation.bigfix.enabled=true

b) BigFix サーバーの設定

v com.collation.bigfix.host=< BigFix サーバーの IP または FQDN>

v com.collation.bigfix.port=<ポート番号>

v com.collation.bigfix.uid=<BigFix サーバー・コンソールにアクセスするためのユーザー ID>

v com.collation.bigfix.pwd=<BigFix サーバー・コンソールにアクセスするためのパスワード>

c) BigFix DB の設定

v com.collation.bigfix.db.type=<MSSQL/DB2>

管理 287

v com.collation.bigfix.db.host=<BigFix サーバー DB の IP または FQDN>

v com.collation.bigfix.db.port=<TADDM が BigFix DB に接続する際のポート>

v com.collation.bigfix.db.dbname=<BigFix DB 名>

v com.collation.bigfix.db.domain=<ユーザー・ドメイン> オプション・パラメーター - BigFix DB に Windows ベースの認証が構成されている場合にのみ必要です

v com.collation.bigfix.db.uid=<BigFix DB にアクセスするためのユーザー ID>

v com.collation.bigfix.db.pwd=<BigFix DB にアクセスするためのパスワード>

d) 結果処理スレッドの設定

v com.ibm.cdb.discover.asd.ProcessUnreachableIPs=true

v com.ibm.cdb.discover.asd.autodiscovery.enabled=true

2. BigFix サーバーで SSL 構成が使用可能になっている場合にのみ、$COLLATION_HOME/etc/collation.properties で以下のプロパティーを設定します。

e) Bigfix 証明書

v com.collation.bigfix.certificate.type=<PKCS12/JKS>

v com.collation.bigfix.certificate.file=<証明書ファイルのフルパス>

v com.collation.bigfix.certificate.pwd=<証明書を使用するためのパスワード>

注: 上記の必須プロパティー以外にも、構成可能なプロパティーが多数あります。プロパティーの完全なリストとそれらの説明については、付録 A を参照してください。

注: 空のパスワードで生成された証明書はサポートされません。

3. スクリプト「encryptprops.sh」を実行してプロパティーを暗号化します (このスクリプトの実行形式を確認するには、付録 C を参照してください)。非暗号化パスワードは受け入れられないため、これを行わないと、ディスカバリー・スクリプト(runBigFixDiscovery.sh/.bat) が引数の欠落、または無効により失敗します (エラー・コードの詳細については付録 E を参照)。

4. TADDM に結果ファイルを保管するための $COLLATION_HOME/var/asdd フォルダーを作成します。var/asdd フォルダーを使用しない場合は、管理者が結果ファイルのダウンロード先として希望する特定のフォルダーを「com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory」プロパティーに設定する必要があります。

5. TADDM を再起動します。

6. セクション 2.1 に記載されている必須センサーを使用してディスカバリー・プロファイルを作成します。プロファイルには、ディスカバーされている他のセンサーに加え、必須センサーが含まれている必要があります。

7. ディスカバリーを実行する必要がある BigFix ターゲット・エンドポイントでディスカバリー・スコープを作成します。


その他の構成:

BigFix サーバーで、サイト名「TADDM」を作成します。

1.「BigFix コンソール」を開きます。->「ツール」タブに移動します。->「カスタム・サイトの作成 (Create Custom Site..)」を選択します。-> サイト名を「TADDM」と指定します。

2.「TADDM」をクリックします。->「コンピューターのサブスクリプション(Computer Subscription)」タブを選択します。-> 要件に基づいてコンピューターをサブスクライブします (TADDM を介して BigFix サーバーが接続する必要があるすべてのコンピューターが含まれている必要があります)。

ログ・ファイルとトラブルシューティングのヒント:

ディスカバリー中に何らかの障害が発生した場合は、以下の事項を確認できます。以下に挙げるすべての前提条件を満たしていることを確認してください。

TADDM ディスカバリー・サーバー

v Bigfix Discovery スクリプトの実行をログで確認する

– $COLLATION_HOME/log/BigFixDiscovery.log

v 結果ファイルが TADDM サーバーに到達しているかどうかをログで確認する

– $COLLATION_HOME/log/services/ApiServer.log (キーワード「BigfixDiscoveryServerController」および「AASDiscoveryServerController」で検索する)

BigFix ルート・サーバー

BigFix ルート・サーバー上の IBM BigFix コンソールを使用し、ディスカバリーとアクション実行のステータスを確認する

1. IBM Bigfix コンソールを開きます。

2. 「サイト」 (「カスタム」->TADDM) ->「Fixlet とタスク」を選択します。

3. 「タスク」(スクリプトの実行時に指定) を選択します。

4. 「詳細」と「アクション履歴」を確認します。

5. 「特定のアクション履歴 (Particular Action History)」->「報告されたコンピューター」を選択します。

6. ステータスを確認します。ダブルクリックすると実行の詳細を確認できます。

7. 「OK」をクリックして「ディスカバリー・プロファイル」ウィンドウに戻ります。

BigFix エージェント/ディスカバリー・ターゲット

v 結果ファイルが %wintemp%"/taddm7.3.0.4/asd フォルダーに存在することを確認する (com.collation.bigfix.endpoint.cleanup プロパティーが「N」に設定されている場合のみ)

v allErrors.txt ファイル (%wintemp%"/taddm7.3.0.4/asd に存在) では、センサー・スクリプトの実行中に発生したエラーをすべて参照可能

管理 289

Bigfix Discovery の実行:

Bigfix Discovery の実行

スコープの作成:

ディスカバリー・スコープを作成するには、TADDM サーバー GUI を開きます。スコープには、すべての BigFix ターゲット・エンドポイントを含める必要がありますターゲット・エンドポイントは、個々のホストとして設定することも、ドメイン/ネットワーク範囲を指定して設定することもできます。

プロファイルの作成:

ディスカバリー・プロファイルは、TADDM サーバー GUI を使用して作成する必要があります。プロファイルには、管理者が TADDM に検出させたいアプリケーション用のセンサーを含める必要があります。作成したディスカバリー・プロファイルに強制的に含める/除外する必要があるセンサーの詳細については、セクション2.1 を参照してください。

スクリプトの実行:

ディスカバリーを実行するには、スクリプト「runBigFixDiscovery.sh」を$COLLATION_HOME/bin から実行します。このスクリプトは、「ディスカバリー」、「ポーリング」、「クリーンアップ」、「再ディスカバリー」の 4 つのモードで実行できます。ディスカバリー・モードでは、ディスカバリーが開始されます。ポーリング・モードでは、現在のディスカバリー状況がフェッチされます。クリーンアップ・モードでは、BigFix ルート・サーバーで結果ファイルのクリーンアップがトリガーされます。再ディスカバリー・モードでは、以前に実行したディスカバリーを再実行できます。

1. ディスカバリー・モード -

TADDM は、以下のアドレスで、Jazz for Service Management にフィード・サービスを提供します。

./runBigFixDiscovery.sh -d -o <output dir> -s <scope> -p <profile>Where,-d – for discovery mode-o - output directory where discovery package would be created-s – input scope, having BigFix endpoints target that are to be discovered.-p – input profile, having sensors to be run

ディスカバリー・モードでこのコマンドが実行されると、ディスカバリーが開始されます。これにより、実行されたステップの状況が表示され、「アクション」の IDが示されます。このアクションは、ポーリング・モードで使用して、各 BigFix エンドポイントでのアクションの状況を確認できます。

注:

v ディスカバリーに対して作成された「ActionID」(コンソール出力に表示される(例えば、以下の例では 2090)) は、ポーリングの目的に再利用できます。

v 特定のスコープとプロファイルに関連付けられている、新しく作成された bigfixタスクの名前 (コンソール出力に表示される「TaskName」(例えば、20180130125432)) を保持してください。再ディスカバリーで再利用できます。


2. ポーリング・モード -

./runBigFixDiscovery.sh -p -r <repetition> -i <Action id>

Where,-p – for poll mode-r – no of times polling will be done to BigFix server-i - Action id obtained from discovery mode command.

3. クリーンアップ・モード -

./runBigFixDiscovery.sh -c -d <No of Days>Where,-c – for cleanup mode-d – Files older than specified number of days to be removed

4. 再ディスカバリー・モード -

./runBigFixDiscovery.sh -r/--rediscover -i <TaskName>Where,-r – for rediscover mode-i – TASK NAME corresponding to the previous discovery, that needs to be run again

注: 可能なすべてのオプションを含むこのコマンドに関する詳細が付録 B に収録されています。また、このコマンドの実行例が付録 C に収録されています。

ディスカバリー結果の処理:

「runBigFixDiscovery.sh」コマンドのポーリング・モードは、各 BigFix エンドポイントで実行されるアクションの状況を示します。状況に基づいて、結果ファイルが作成されて処理されます。

1. エンドポイントに対してアクションが正常に完了すると、そのエンドポイントの結果ファイルが、設定された結果フォルダーにダウンロードされます (デフォルトの結果フォルダーは var/asdd です。結果フォルダーの設定については、セクション 2.3.1 を確認してください)。

2. エンドポイントに対してアクションが正常に完了すると、そのエンドポイントの結果ファイルが、設定された結果フォルダーにダウンロードされます (デフォルトの結果フォルダーは var/asdd です。結果フォルダーの設定については、セクション 2.3.1 を確認してください)。

3. 結果ファイルが正常に処理されると、TADDM GUI の履歴タブで結果を確認できるようになります。

4. 処理された結果データは TADDM データベースに格納され、TADDM のデータ管理ポータルや PSS で利用できるようになります。

起こりうる障害のシナリオ:

ディスカバリー、ポーリング、クリーンアップ、または再ディスカバリーの各モードで何らかの障害が発生した場合は、以下の事項を確認できます。

1. セクション 2.2 に記載されている前提条件をすべて満たしていることを確認します。

2. 以下のパスの TADDM ログを確認します。

管理 291

v $COLLATION_HOME/log/BigFixDiscovery.log – ディスカバリーおよびスクリプト実行のログ

v $COLLATION_HOME/log/services/ApiServer.log – 結果の取り出しと構文解析のログ

3. 障害の状況について、BigFix サーバー・ログと BigFix コンソールを確認します。

4. 「アクションのポーリング」が「ルート・サーバー」および「エンドポイント」から失敗する場合には、Bigfix アクション・スクリプトの実行ログを確認できます。

付録 A. 統合で使用される Collation.Properties1. BigFix 機能の有効化

表 50.

プロパティー名指定できる値説明必須

com.collation.bigfix.enabled

true/false true の場合、BigFix 機能が有効になります。このプロパティーを true に設定した後は、TADDM の再始動が必要です。

Y

2. BigFix サーバー

表 51.


com.collation.bigfix.host

IP または FQDN BigFix サーバーの IPまたは FQDN。

Y

com.collation.bigfix.port

<ポート番号>

デフォルト=52311

TADDM が BigFix サーバーに要求を送信するポート。

N

com.collation.bigfix.uid

<ユーザー ID> BigFix サーバー・コンソールにアクセスするためのユーザー ID。

Y

com.collation.bigfix.pwd

<password> BigFix サーバー・コンソールにアクセスするためのパスワード。暗号化形式で保管されます。

Y

com.collation.bigfix.connectTo

<time_period> デフォルト=20 秒

TADDM は、HTTP/RestAPI 接続がタイムアウトするまでこの期間 (秒単位) を待機します。

N

com.collation.bigfix.responseTo

<time_period> デフォルト=20 秒

TADDM は、HTTP 応答がタイムアウトするまでこの期間 (秒単位) を待機します。

N


表 51. (続き)


com.collation.bigfix.site.type

<site_type> デフォルト=custom

TADDM の接続に使用する、BigFix サーバーのサイトのタイプ。

N

Visibility.Control.Automation

<site_name> デフォルト=TADDM

TADDM の接続に使用する、BigFix サーバーのサイトの名前。

N

com.collation.bigfix.aasdpkgmaxsize

<要求パッケージのサイズ> デフォルト=1024

BigFix Discovery スクリプトによって生成される要求パッケージの最大許容サイズ。

N

3. BigFix サーバー証明書

表 52.


com.collation.bigfix.certificate.type

<PKCS12/JKS>デフォルト=JKS

サポートされるクライアント証明書のタイプ。

N

com.collation.bigfix.certificate.file

<パス> クライアント証明書ファイルの場所。

N

com.collation.bigfix.certificate.pwd

<パスワード> クライアント証明書のパスワード

N

4. BigFix サーバー DB

表 53.


com.collation.bigfix.db.type

MSSQL または DB2

BigFix サーバーが使用する DB のタイプ。Windows ベースのBigFix サーバーの場合はMSSQL、Linux ベースの場合はDB2。

Y

com.collation.bigfix.db.host

IP またはFQDN

BigFix DB の IP または FQDN。 Y

com.collation.bigfix.db.port

<ポート番号>

TADDM が BigFix DB に接続する際のポート。

Y

com.collation.bigfix.db.dbname

<DB 名> BigFix DB の名前。 Y

com.collation.bigfix.db.domain

<ユーザー・ドメイン>

ユーザーのドメイン。Windows ベースの認証の場合は必須。

N

com.collation.bigfix.db.domain

<ユーザーID>

BigFix DB にアクセスするためのユーザー ID。

Y

com.collation.bigfix.db.pwd

<password> BigFix DB にアクセスするためのパスワード。暗号化形式で保管されます。

Y

管理 293

障害の状況については、BigFix サーバー・ログと BigFix コンソールを確認します。

注:

v TADDM-DB の接続が切れた場合、TADDM は「com.collation.bigfix.result.wait」の設定に従って再接続を試行します。

v 上記設定に何らかの変更を加えた場合は、TADDM を再始動する必要があります。

5. TADDM - 結果フェッチ/処理スレッド

表 54.


com.collation.bigfix.result.wait

<秒単位の値>デフォルト=60秒

「com.collation.bigfix.enabled」が有効になっていると、BigFixサーバーからディスカバリー結果ファイルを定期的に取り出すための結果フェッチ・スレッドが生成されます。「結果フェッチ・スレッド」は、設定された周期 (秒単位で定義) に従って BigFix サーバーから結果パッケージを取り出します。

N

com.ibm.cdb.discover.asd.autodiscovery.enabled

true/false true の場合、スレッドは格納された ASD 結果ファイルを処理できます。

Y

com.ibm.cdb.discover.asd.ProcessUnreachableIPs

true/false スレッドが、到達できないターゲットの ASD 結果を処理します。

Y

com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory

パスのデフォルト =var/asdd

結果ファイルが保持される場所のパス。パスは構成可能ですが、デフォルトでは var/asdd に設定されています。

N

com.ibm.cdb.discover.asd.autodiscovery.asdScope

<スコープ名>デフォルト =ASD

スレッドは、このスコープに指定されたターゲットを選択して結果ファイルを処理します。このプロパティーが指定されない場合は、デフォルトの ASD スコープが処理されます。

N

com.ibm.cdb.discover.asd.autodiscovery.asdProfile

<プロファイル名>デフォルト =ASD

スレッドは、このプロファイルに指定されたセンサーを選択して結果ファイルを処理します。このプロパティーが指定されない場合は、デフォルトの ASD プロファイルが処理されます。

N


表 54. (続き)


com.ibm.cdb.discover.asd.autodiscovery.filesThreshold

<ファイルしきい値>デフォルト=20

スレッドが処理を開始するために必要とする最小ファイル数。スレッドは、ファイルしきい値または時間しきい値のいずれかに達した場合に結果を処理します。

N

com.ibm.cdb.discover.asd.autodiscovery.timeThreshold

<時間しきい値>デフォルト=60秒

時間しきい値を超えると、ファイルしきい値に達していなくても、スレッドは結果ファイルを処理します。

N

注: 1. BigFix Discovery の結果は TADDM サーバーに非同期に到着し、いずれかのプロパティー (com.ibm.cdb.discover.asd.autodiscovery.filesThreshold,com.ibm.cdb.discover.asd.autodiscovery.timeThreshold) に達すると、一連の使用可能な結果ファイルが処理され、その結果、新しい「ディスカバリー履歴」エントリーが作成されます。これらのプロパティーは、「ディスカバリー履歴」エントリーの数を制御するための特定の要件に従って微調整されます。

6. クリーンアップ

表 55.

連番リソースTADDM サーバー

BES ルート・サーバー BES エンドポイント

作成クリーンアップ



1. 要求パッケージ

Y N1 Y N2 Y Y

2. タスク - - Y Y 4 - -

3. アクション - - Y Y 3 - -

4. 結果パッケージ

Y Y Y Y Y Y

5. ファイル・セット

- - - - Y Y

注:

v TADDM サーバーでの要求パッケージのクリーンアップはサポートされていません。

v BES ルート・サーバーでの要求パッケージのクリーンアップはサポートされていません。(要求パッケージは再ディスカバリー時に再使用される可能性があります)

v TADDM によって作成され、有効期限切れ状態になっているアクションのみが、クリーンアップの対象と見なされます (ただし TADDMCLEANUP という名前で作成されたアクションを除く)。

管理 295

v TADDM によって作成されたタスクは、そのタスクに関連付けられたすべてのアクションが削除済みである場合にのみ、削除されます。

v

– 再ディスカバリーに対応するため、特定のタスクとその関連アクションをクリーンアップから除外するには、以下の詳細に従って retainBigFixTask.sh/.bat を使用できます。

使用法: ./retainBigFixTask.sh <TaskName> <enable/disable>

TADDM サーバーでのクリーンアップ

表 56.


com.collation.bigfix.taddm.cleanup.volume

<制限サイズとサフィックス>

<この制限サイズを超えると、古い処理ファイルが削除されます。例: 50MB、2GB など>

N

com.collation.bigfix.taddm.cleanup.time

<制限時間とサフィックス>

<設定された単位よりも古い処理ファイルを確認します。例:1D、5H、30M など>

N

com.collation.bigfix.taddm.cleanup.runtime

分数 TADDM クリーンアップ・スレッドは、実行後に設定された分数を待機します。

N

注:

v TADDM サーバーでの結果ファイルのクリーンアップは、少なくとも 1 つのプロパティー(com.collation.bigfix.taddm.cleanup.volume、com.collation.bigfix.taddm.cleanup.time)が構成されている場合にのみ行われます。

エンドポイントでのクリーンアップ

表 57.


com.collation.bigfix.endpoint.cleanup

<Y または N><デフォルト=Y>

Y に設定すると、要求パッケージの zip、展開された要求パッケージ・ディレクトリー、および新しく作成された結果パッケージの zip がエンドポイントから削除されます。

N

BigFix ルート・サーバーでのクリーンアップ


表 58.


com.collation.bigfix.root.cleanup.interval

<日数> <デフォルト=1>

クリーンアップ・タスクを実行し、結果パッケージ、タスク、および期限切れアクションを BES ルート・サーバーから削除する周期。

N

com.collation.bigfix.root.cleanup.days


指定された日数より古い結果ファイルは、削除対象と見なされます。

N

7. カスタム関連性

表 59.


com.collation.bigfix.relevance.appendscope

true/false<デフォルト=true>

true の場合、指定されたスコープに加えて、カスタム関連性照会が使用されます。

false の場合、指定されたスコープではなく、カスタム関連性照会のみが使用されます。

N

com.collation.bigfix.relevance

true/false 指定されたディスカバリーの一連のエンドポイントを識別するための関連性照会。

N

8. Bigfix パッケージの一時パスの設定

表 60.


com.collation.bigfix.action.enable.os

<設定された OSのアクション・スクリプト><デフォルト=Windows, AIX,Linux, SunOS>

設定された OS のアクション・スクリプトが BigfixActionScript に含まれます

N

com.collation.bigfix.temp.Windows

要求パッケージのパス<デフォルト=C:¥Windows¥Temp>

ASD 要求パッケージに使用されるパス。*注: Windows のパスでは「¥」を「¥¥」と指定する必要があります。

N

com.collation.asd.temp.Windows

結果パッケージのパス<デフォルト=C:¥Windows¥Temp>

ASD 結果パッケージに使用されるパス。

N

管理 297

表 60. (続き)


com.collation.asd.temp.Unix

結果パッケージのパス<デフォルト=/tmp>


N

com.collation.bigfix.temp.Linux

結果パッケージのパス <デフォルト=/tmp>

ASD 要求パッケージに使用されるパス。

N

com.collation.bigfix.temp.SunOS



N

com.collation.bigfix.temp.AIX



N

注: 設定された上記の一時パスに基づき、ターゲット・エンドポイントにフォルダーがなければ作成されます。例えば Windows 2003 の場合、一時パスにはデフォルトの「C:¥Windows¥Temp¥」が使用され、ディスカバリー時にこのフォルダーが作成されます。

付録 B. 各モードのスクリプト・パラメーターのヘルプ./runBigFixDiscovery.sh - BigFix 拡張ディスカバリーを実行したり、既存のディスカバリー・アクションを照会したりするための TADDM ツール。

モード: ディスカバー

使用法: bin/runBigFixDiscovery.sh -d/--discover [-c <arg>] [-freq <arg>] [-h][-intr <arg>] -o <arg> -p <arg> -s <arg>

各部の意味は以下のとおりです。

表 61.

-c、--compressMethod <arg> [デフォルト: ZIP] 指定できる値:[ZIP、TAR]。

-freq、--frequency <arg> [デフォルト: 1] ディスカバリーを実行する必要がある回数。

-h、--help ヘルプを表示します。

-intr、--interval <arg> [デフォルト: P1D] ディスカバリーの再実行の時間間隔。サポートされる値: [PT15M,PT30M, PT1H, PT2H, PT4H, PT6H, PT8H,PT12H, P1D, P2D, P3D, P5D, P7D, P15D,P30D]。

-o、--output <arg> 必須: Bigfix ディスカバリー・パッケージが生成される出力ディレクトリー。


表 61. (続き)

-p、--profile <arg> 必須: ディスカバリー・パッケージの作成でセンサーを含めるためにプロファイル名が使用されます。

-s、--scope 必須: スコープ/スコープ・グループ名 (コンマ区切り。スペースを含む名前は引用符で囲む)。

モード: ポーリング

使用法: bin/runBigFixDiscovery.sh -p/--poll [-h] -i <arg> [-r <arg>] [-t <arg>]


表 62.

-d、--detail <arg> [デフォルト: true] 各エンドポイントのポーリング結果


-r、--repeat <arg> [デフォルト: 1] アクション状況をポーリングする回数

-i、--id <arg> 必須: ポーリングするアクション ID

-t、--timeout <arg> [デフォルト: 1] 連続するポーリングの間隔(秒単位)

モード: クリーンアップ

使用法: bin/runBigFixDiscovery.sh -c/--cleanup [-d <arg>] [-h]


表 63.


-d、--days <arg> [デフォルト: 5] 指定された日数よりも古い結果ファイルをクリーンアップします

モード: 再ディスカバー

使用法: bin/runBigFixDiscovery.sh -r/--rediscover [-freq <arg>] [-h] [-intr <arg>]


表 64.

-freq、--frequency <arg> [デフォルト: 1] ディスカバリーを実行する必要がある回数


管理 299

表 64. (続き)

-intr、--interval <arg> [デフォルト: P1D] ディスカバリーの再実行の時間間隔。サポートされる値: [PT15M,PT30M, PT1H, PT2H, PT4H, PT6H, PT8H,PT12H, P1D, P2D, P3D, P5D, P7D, P15D,P30D]。

5. TADDM - 結果フェッチ/処理スレッド

表 65.


com.collation.bigfix.result.wait

<秒単位の値>デフォルト=60 秒

「com.collation.bigfix.enabled」が有効になっていると、BigFix サーバーからディスカバリー結果ファイルを定期的に取り出すための結果フェッチ・スレッドが生成されます。「結果フェッチ・スレッド」は、設定された周期 (秒単位で定義) に従って BigFix サーバーから結果パッケージを取り出します。

N

com.ibm.cdb.discover.asd.autodiscovery.enabled

true/false true の場合、スレッドは格納された ASD 結果ファイルを処理できます。

Y

com.ibm.cdb.discover.asd.ProcessUnreachableIPs

true/false スレッドが、到達できないターゲットの ASD 結果を処理します。

Y

com.ibm.cdb.discover.asd.AsyncDiscoveryResultsDirectory

パスのデフォルト =var/asdd

結果ファイルが保持される場所のパス。パスは構成可能ですが、デフォルトでは var/asdd に設定されています。

N

com.ibm.cdb.discover.asd.autodiscovery.asdScope

<スコープ名>デフォルト =ASD

スレッドは、このスコープに指定されたターゲットを選択して結果ファイルを処理します。このプロパティーが指定されない場合は、デフォルトの ASD スコープが処理されます。

N

com.ibm.cdb.discover.asd.autodiscovery.asdProfile

<プロファイル名>デフォルト =ASD

スレッドは、このプロファイルに指定されたセンサーを選択して結果ファイルを処理します。このプロパティーが指定されない場合は、デフォルトの ASD プロファイルが処理されます。

N

com.ibm.cdb.discover.asd.autodiscovery.filesThreshold

<ファイルしきい値>デフォルト=20

スレッドが処理を開始するために必要とする最小ファイル数。スレッドは、ファイルしきい値または時間しきい値のいずれかに達した場合に結果を処理します。

N


表 65. (続き)


com.ibm.cdb.discover.asd.autodiscovery.timeThreshold

<時間しきい値>デフォルト=60 秒

時間しきい値を超えると、ファイルしきい値に達していなくても、スレッドは結果ファイルを処理します。

N

注: 1. BigFix Discovery の結果は TADDM サーバーに非同期に到着し、いずれかのプロパティー (com.ibm.cdb.discover.asd.autodiscovery.filesThreshold,com.ibm.cdb.discover.asd.autodiscovery.timeThreshold) に達すると、一連の使用可能な結果ファイルが処理され、その結果、新しい「ディスカバリー履歴」エントリーが作成されます。これらのプロパティーは、「ディスカバリー履歴」エントリーの数を制御するための特定の要件に従って微調整されます。

6. クリーンアップ

表 66.

連番リソースTADDM サーバー

BES ルート・サーバー BES エンドポイント




1. 要求パッケージ

Y N1 Y N2 Y Y

2. タスク - - Y Y 4 - -

3. アクション - - Y Y 3 - -

4. 結果パッケージ

Y Y Y Y Y Y

5. ファイル・セット

- - - - Y Y

注:

v TADDM サーバーでの要求パッケージのクリーンアップはサポートされていません。

v BES ルート・サーバーでの要求パッケージのクリーンアップはサポートされていません。(要求パッケージは再ディスカバリー時に再使用される可能性があります)

v TADDM によって作成され、有効期限切れ状態になっているアクションのみが、クリーンアップの対象と見なされます (ただし TADDMCLEANUP という名前で作成されたアクションを除く)。

v TADDM によって作成されたタスクは、そのタスクに関連付けられたすべてのアクションが削除済みである場合にのみ、削除されます。

v

– 再ディスカバリーに対応するため、特定のタスクとその関連アクションをクリーンアップから除外するには、以下の詳細に従って retainBigFixTask.sh/.bat を使用できます。

管理 301

使用法: ./retainBigFixTask.sh <TaskName> <enable/disable>

TADDM サーバーでのクリーンアップ

表 67.


com.collation.bigfix.taddm.cleanup.volume

<制限サイズとサフィックス>

<この制限サイズを超えると、古い処理ファイルが削除されます。例: 50MB、2GB など>

N

com.collation.bigfix.taddm.cleanup.time

<制限時間とサフィックス>

<設定された単位よりも古い処理ファイルを確認します。例:1D、5H、30M など>

N

com.collation.bigfix.taddm.cleanup.runtime

分数 TADDM クリーンアップ・スレッドは、実行後に設定された分数を待機します。

N

注:

v TADDM サーバーでの結果ファイルのクリーンアップは、少なくとも 1 つのプロパティー(com.collation.bigfix.taddm.cleanup.volume、com.collation.bigfix.taddm.cleanup.time)が構成されている場合にのみ行われます。

エンドポイントでのクリーンアップ

表 68.


com.collation.bigfix.endpoint.cleanup

<Y または N><デフォルト=Y>

Y に設定すると、要求パッケージの zip、展開された要求パッケージ・ディレクトリー、および新しく作成された結果パッケージの zip がエンドポイントから削除されます。

N

BigFix ルート・サーバーでのクリーンアップ

表 69.


com.collation.bigfix.root.cleanup.interval


クリーンアップ・タスクを実行し、結果パッケージ、タスク、および期限切れアクションを BES ルート・サーバーから削除する周期。

N

com.collation.bigfix.root.cleanup.days


指定された日数より古い結果ファイルは、削除対象と見なされます。

N

7. カスタム関連性


表 70.


com.collation.bigfix.relevance.appendscope

true/false<デフォルト=true>

true の場合、指定されたスコープに加えて、カスタム関連性照会が使用されます。

false の場合、指定されたスコープではなく、カスタム関連性照会のみが使用されます。

N

com.collation.bigfix.relevance

true/false 指定されたディスカバリーの一連のエンドポイントを識別するための関連性照会。

N

8. Bigfix パッケージの一時パスの設定

表 71.


com.collation.bigfix.action.enable.os

<設定された OS のアクション・スクリプト><デフォルト=Windows,AIX, Linux, SunOS>

設定された OS のアクション・スクリプトが BigfixActionScript に含まれます

N

com.collation.bigfix.temp.Windows

要求パッケージのパス<デフォルト=C:¥Windows¥Temp>

ASD 要求パッケージに使用されるパス。*注: Windows のパスでは「¥」を「¥¥」と指定する必要があります。

N

com.collation.asd.temp.Windows

結果パッケージのパス <デフォルト=C:¥Windows¥Temp>


N

com.collation.asd.temp.UNIX



N

com.collation.bigfix.temp.Linux



N

com.collation.bigfix.temp.SunOS



N

com.collation.bigfix.temp.AIX



N

注: 設定された上記の一時パスに基づき、ターゲット・エンドポイントにフォルダーがなければ作成されます。例えば Windows 2003 の場合、一時パスにはデフォルトの「C:¥Windows¥Temp¥」が使用され、ディスカバリー時にこのフォルダーが作成されます。

管理 303

付録 C. スクリプト実行の確認例1. 実行スクリプト - encryptprops.sh

/opt/IBM/taddm/dist/bin/encryptprops.sh $COLLATION_HOME

2. 実行スクリプト – runBigFixDisocvery.sh

TADDM Server – 9.167.42.227 (Linux)BigFix server – 10.160.161.195 (windows)BigFix endpoints – 10.160.161.196 (windows)

10.160.161.212 (windows)Scope – ASD (having both BigFix endpoints)Profile - ASD (having sensors mentioned in section 2.2)Configuration - done as per section 3.

a. ディスカバリーの開始:

[taddmusr@nc042227 bin]$ ./runBigFixDiscovery.sh -d -o /tmp -p ASD -s ASDBigFix Action will be applied total [1] times with [P1D] interval

Task created on BES server with Name [20170828083852] and Action created with ID [633]

DISCOVER: LAUNCH OKThe Bigfix Discovery script exited successfully.

b. タスク名 – 20170828083852、アクション ID – 633

c. ポーリングの開始:

[taddmusr@nc042227 bin]$ ./runBigFixDiscovery.sh -p -i 633Repeatedly poll the BigFix Action [1] number of times for every [1] secondsTotal [2] Computers returned for Action with ID [633] has status: Open

Total [1] computers with status : The action executed successfully.[Hostname] [Apply Count] [Line Number] [Start Time] [End Time][PNC161196] [1] [98] [Mon, 28 Aug 2017 14:43:56 +0000] [Mon, 28 Aug 2017 14:44:11 +0000]

Total [1] computers with status : The action failed.[Hostname] [Apply Count] [Line Number] [Start Time] [End Time][PRODUCTIONWASB] [1] [37] [Mon, 28 Aug 2017 07:40:26 +0000] [Mon, 28 Aug 2017 07:40:26 +0000]

POLL FINISHEDThe Bigfix Discovery script exited successfully

クリーンアップの開始:

[taddmusr@nc042227 bin]$ ./runBigFixDiscovery.sh -cCLEANUP TASK FOUND: TADDMCLEANUP with ID: 2067

Cleanup Action created with ID: [2068]

CLEANUP: LAUNCH OKThe Bigfix Discovery script exited successfully

再ディスカバリーの開始:

[taddmusr@nc042227 bin]$ ./runBigFixDiscovery.sh –r –i 20171117085907

TASK FOUND : 20171117085907 with ID : 2075

Action created with ID: [2086]

REDISCOVERY: LAUNCH OKThe Bigfix Discovery script exited successfully.


付録 D. エラー・コードと説明

表 72.

メッセージ ID M: メッセージ、C: 原因、E: 影響

CTJTD1260E M: Bigfix Discovery が有効になっていません。collation.propertiesの com.collation.bigfix.enabled を構成してください

E: Bigfix Discovery スクリプトは実行されず、結果を取り出すためのスレッドは呼び出されません

CTJTD1261E M: 引数が欠落しているか正しくありません

C: ディスカバー、ポーリング、クリーンアップ、または再ディスカバー以外のモードでスクリプトを実行しようとしています

E: スクリプトは実行されません

CTJTD1262E M: 指定された数字フォーマットが正しくありません

C: 数値形式で指定する必要があるプロパティーまたは引数が文字列形式で指定されています

E: Bigfix Discovery スクリプトは実行されず、結果を取り出すためのスレッドが正常に機能しません

CTJTD1263E M: コマンド行プロパティーの構文解析に失敗しました: <プロパティー名>

C: スクリプトの実行時に渡された引数はサポートされていません

E: スクリプト・モードは呼び出されません

CTJTD1264E M: collation.properties に <プロパティー名> がありません

C: スクリプトの実行時に必要なプロパティーがないか、無効です(付録 A を参照)

E: Bigfix Discovery スクリプトは実行されず、結果を取り出すためのスレッドが正常に機能しません

CTJTD1265I M: 指定されたスコープの代わりに、カスタム関連性のみが使用されます

CTJTD1266I M: 指定されたスコープに加えて、カスタム関連性が使用されます

CTJTD1267E M: 空のスコープが指定されました。エレメントが見つかりませんでした

C: 指定されたスコープ/スコープ・グループにエンドポイントを定義する要素が含まれていません

E: ディスカバリーは起動されません

CTJTD1268E M: 指定されたプロファイルにセンサーが存在しないか、または有効になっていません

C: 指定されたプロファイルにセンサーが含まれていません


管理 305

表 72. (続き)

メッセージ ID M: メッセージ、C: 原因、E: 影響

CTJTD1269E M: AASD 要求パッケージが存在しません

C: 要求パッケージの作成中に問題が発生したか、アップロードする権限がないか、権限が存在しません


CTJTD1270E M: AASD パッケージのサイズが、構成されたcom.collation.bigfix.aasdpkgmaxsize しきい値を超えています

C: 作成された要求パッケージのサイズが構成よりも大きいです


CTJTD1271E M: 次の理由により、BigFix に接続できません: <理由>

C: 無効なパラメーター/無効な証明書による Bigfix Web サービス接続の問題です E: パッケージはアップロードされず、ディスカバリーは起動されません

CTJTD1272E M: セットアップ中にエラーがキャッチされました: <理由>

C: 処理されないコードの予期しないシナリオです

E: スクリプトの実行が正常に機能しません

CTJTD1273I M: BigFix Discovery の (再) 実行、または指定されたディスカバリー・アクションのポーリング、または手動クリーンアップを行うためのメイン・スクリプト


特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。

国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、変更があれば本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

© Copyright IBM Corp. 2006, 2018 307

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

商標IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された InternationalBusiness Machines Corporation の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml をご覧ください。


Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における登録商標です。

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

特記事項 309

IBM®

Printed in Japan

application dependency discovery managern...本書は、 ibm tivoli application dependency discovery...

Documents