ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド
11g リリース1 (11.1.1.7.0)
B72436-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

8 管理および監視の要件の特定

この章では、Oracle Directory Server Enterprise Edition (ODSEE)デプロイメントの計画フェーズで、管理に関して決定する必要がある事項の概要について説明します。

8.1 ODSEE管理モデルの概要

ODSEE管理モデルでは、コマンドライン・ユーティリティ、Directory Service Control Center (DSCC)と呼ばれるコンソールおよびリモート管理を実現するDSCCエージェントを利用します。このモデルでは、管理者がサーバー・インスタンスの作成およびサーバー管理を制御します。

8.1.1 管理のためのコマンドライン・ユーティリティ

dsadmおよびdsconfコマンドライン・ユーティリティでは、そのすべての機能以外に、Directory Server Enterprise Edition 5.xリリースのdirectoryserverユーティリティによって提供される機能も使用できます。

dsadmユーティリティを使用すると、管理者はDirectory Serverインスタンスを作成、起動および停止できます。dsadmコマンドによって、Directory Serverインスタンスへのファイル・システム・アクセスを必要とするすべての操作が結合されます。dsadmコマンドは、このインスタンスをホストしているマシン上で実行する必要があります。dsadmユーティリティでは、インスタンスへのLDAPアクセスまたはエージェントへのアクセスが必要な操作は実行されません。

DSEEリリース6.0以下と異なり、現在の管理モデルでは、Directory ServerインスタンスはServerRootと関連付けられていません。各Directory Serverインスタンスは、そのインスタンス独自のファイル・システムのロケーションやパスに配置できます。

dsconfユーティリティによって、cn=configへの書込みアクセスが必要な管理操作が結合されます。dsconfユーティリティは、LDAPクライアントです。アクティブなDirectory Serverインスタンスでのみ実行できます。dsconfコマンドはリモートで実行できるため、管理者は単一のリモート・マシンから複数のインスタンスを構成できます。

Directory Proxy Serverには、dpadmおよびdpconfという、類似する2つのコマンドがあります。dpadmコマンドを使用すると、管理者はDirectory Proxy Serverインスタンスを作成、起動および停止できます。dpconfコマンドを使用すると、管理者はLDAPを使用してDirectory Proxy Serverを構成し、Directory Proxy Server経由でDirectory Server構成にアクセスできます。

8.1.2 Directory Service Control Center (DSCC)

Directory Service Control Centerは、Directory ServerおよびDirectory Proxy Serverのインスタンスを管理するためのWebインタフェースです。DSCCは、次の3つのコンポーネントで構成されます。

8.1.2.1 DSCC Webインタフェース

DSCC Webインタフェースには、コマンドライン・ユーティリティと同じ機能以外に、複数のサーバーを同時に構成できるウィザードも備えられています。また、DSCCにはレプリケーション・トポロジ描画ツールも備えられており、レプリケーション・トポロジをグラフィカルに監視できるようになります。このツールによって、個々のマスター、ハブ、コンシューマおよびこれらの間のレプリケーション承諾がリアルタイムに表示され、レプリケーション監視が簡易化されます。DSCCにアクセスする方法の詳細およびDSCC管理者の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。

DSCCはWebアプリケーション(WARファイル)であり、これをサポートするWebサーバーまたはアプリケーション・サーバーにデプロイする必要があります。インストール手順の詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』を参照してください。

8.1.2.2 DSCCエージェント

DSCCエージェントは、DSCCからサーバー・ホストにdsadmコマンドおよびdpadmコマンドを実行できるようにするデーモンであり、これにより、DSCCで次のことを実行できます。

  • サーバー・インスタンスの作成

  • サーバー・インスタンスの起動

  • サーバー・インスタンスのログの表示

  • サーバー・インスタンス証明書の管理

サーバー・ホストにODSEEをインストールするたびに、そのホストのDSCCサーバー・インスタンスから管理するためのDSCCエージェントを作成できます。

DSCCエージェントは、その所有者と同じユーザーに属するサーバー・インスタンスのみを管理できます。複数のDSCCエージェントを作成すると、別のユーザーが所有するサーバー・インスタンスを管理できます。

デフォルトでは、DSCCエージェントはポート3997で稼働します。

8.1.2.3 DSCCレジストリ

DSCCレジストリ(別名をads)は、dsccsetup ads-createコマンドを使用すると自動的に作成される、プライベートなDirectory Serverインスタンスです。DSCCレジストリの唯一の目的は、管理対象のすべてのDirectory ServerインスタンスおよびDirectory Proxy Serverインスタンスのレジストリ・データを保持することです。

サーバー・ホストをインストールするたび、DSCCレジストリにDSCCエージェントを登録する必要があります。また、DSCCエージェントによって管理されるすべてのDirectory ServerまたはDirectory Proxy Serverのインスタンスも、DSCCレジストリに追加する必要があります。

登録が完了すると、DSCCを使用して、登録済Directory ServerまたはDirectory Proxy Serverのインスタンスを管理できます。DSCCエージェントによって、サーバー・ホストにインストールされたDirectory ServerおよびDirectory Proxy Serverのインスタンスの作成、削除および実行前構成が安全に管理されます。

登録されたDirectory ServerおよびDirectory Proxy Serverのインスタンスの構成は、DSCCレジストリではなく、インスタンス自体に保持されます。構成は、LDAPのリスニング・ポートを介して読み取られます。

DSCC Webアプリケーションは、実行時に登録済のDirectory ServerおよびDirectory Proxy Serverをポーリングします。Webインタフェースが使用中であり、管理ユーザーがUIを介してナビゲートしている場合、管理対象のホストに対する問合せがWebアプリケーションによって直接実行され、必要な構成とステータスの情報を使用して、DSCC Webページが更新されます。

Directory ServerまたはDirectory Proxy Serverインスタンスの登録中、サーバー・インスタンスは、DSCC管理者がサーバー構成に読取り/書込みアクセスできるように構成されます。

  • Directory Serverインスタンスの場合は、ACIが作成され、パススルー認証プラグインが有効になります。cn=dsccを含む管理バインドDNの場合は、プラグインによって認証がDSCCレジストリにリダイレクトされます。

  • Directory Proxy Serverインスタンスの場合は、DSCC管理者専用の接続ハンドラが作成され、dccAdminSuffixcn=Administrators,cn=dsccに設定されます。

DSCCレジストリがオフラインの場合、DSCC管理ユーザーはDirectory Serverインスタンスにアクセスしたり、Directory Serverインスタンスを管理できません。ただし、サーバー構成に対してローカルなDirectory ServerおよびDirectory Proxy Server Managerのアカウントは管理できます。

8.1.3 リモート管理

Directory Server Enterprise Editionの管理モデルを使用すると、トポロジ内の任意のDirectory ServerまたはDirectory Proxy Serverをリモートで管理できます。サーバーのリモート管理には、コマンドライン・ユーティリティとDSCCの両方を使用できます。

dsadmおよびdpadmの各ユーティリティは、リモートからは実行できません。これらのユーティリティは、管理対象のサーバー・インスタンスと同じマシンにインストールして、実行する必要があります。dsadmおよびdpadmによって提供される機能の詳細は、dsadmおよびdpadmのマニュアル・ページを参照してください。

dsconfおよびdpconfの各ユーティリティは、リモートで実行できます。dsconfおよびdpconfによって提供される機能の詳細は、dsconfおよびdpconfのマニュアル・ページを参照してください。

次の図は、この新しい管理モデルによって、リモート管理が容易になる仕組みを示しています。この図では、DSCCおよび構成コマンド(dsconfおよびdpconfig)は、Directory ServerおよびDirectory Proxy Serverのインスタンスからリモートでインストールされ、実行されています。管理コマンドは、これらのインスタンスに対してローカルに実行する必要があります。

DSCCにログインするとき、管理者の資格証明を指定すると、DSCCにより、認証がDSCCレジストリに委任されます。認証されると、LDAP通信を使用して、登録済のサーバーを管理できます。

特定の操作でdsadmまたはdpadmを使用する必要がある場合は、DSCCエージェントを使用してサーバーに接続する必要があります。このため、たとえば、Directory Serverインスタンスを起動する場合には、DSCC管理者の資格証明を指定します。この場合は、DSCCエージェントを介し、同じ管理者の資格証明を使用してDSCCレジストリに認証が委任されます。(DSCCレジストリに対して認証するために指定した管理者の資格証明に加えて、OSベースの資格証明は指定しません。)

Directory Serverがすべて同じユーザーによって管理される場合にのみ、1つのDSCCエージェントで複数のDirectory Serverを管理できます。異なるユーザーとして稼働する複数のサーバー・インスタンスが必要である場合は、複数のDSCCエージェント・インスタンスをインストールして実行する必要があります。

図8-1 Directory Server Enterprise Editionの管理モデル

図8-1は、周囲のテキストで説明されています。

8.2 バックアップおよびリストア・ポリシーの設計

データの破損や損失を伴う障害が発生した状況では、データの最新のバックアップを保有していることが必要になります。可能な場合は、他のサーバーからサーバーを再初期化しないようにしてください。データをバックアップする方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第8章「Directory Serverのバックアップおよびリストア」を参照してください。

この項では、バックアップおよびリカバリ計画を作成する場合の考慮事項の概要について説明します。

8.2.1 バックアップおよびリカバリの基本原則

バックアップ計画を設計する場合は、次の基本原則を適用します。

  • バックアップする必要のあるデータを特定します。

    Directory Server Enterprise Editionの場合、このようなデータには次のものが含まれます。

    • 共有されているバイナリおよびプラグイン

    • 証明書データベースのファイル

    • 構成ファイル

    • ログ・ファイルおよび変更ログ・データベース

    • スキーマ・ファイル

    • ユーザー・データ

  • バックアップおよびリカバリ計画に、ハードウェア、オペレーティング・システムおよびソフトウェア・コンポーネントが含まれていることを確認します。

  • バイナリ・バックアップまたはLDIFバックアップを保持するかどうかを決定します。

    通常は、この両方を保持することをお薦めします。詳細は、「バックアップ方法の選択」および「リストア方法の選択」を参照してください。

  • バックアップおよびリカバリ・ツール関連の自動化を構築し、自動化スクリプトが保守されるようにします。

    この方針によって、緊急でバックアップからのリストアが必要になった場合に、不必要な遅延が回避されます。

  • 保存とローテーションの方針を決定します。

    この方針には、バックアップの実行頻度およびバックアップの保存期間が含まれています。バックアップの保存とローテーションを決定する場合は、パージ遅延と、レプリケートされるトポロジ内のバックアップに対してその遅延が及ぼす影響に注意してください。サプライヤで変更が発生すると、その変更は変更ログに記録されます。変更ログを空にする方法がないと、使用可能なすべてのディスク領域が変更ログによって消費されるまで、ログのサイズが増大し続ける場合があります。デフォルトでは、変更は7日ごとに消去されます。この期間をパージ遅延と呼びます。変更は、消去されるとレプリケートできなくなります。このため、少なくともパージ遅延と同じ頻度で、データベースをバックアップする必要があります。

  • 単にシステムのバックアップおよびリカバリを実行するのではなく、Directory Server Enterprise Editionに搭載されているバックアップおよびリカバリ・ツールを使用します。

8.2.2 バックアップ方法の選択

Directory Server Enterprise Editionでは、バイナリ・バックアップおよびLDIFファイルへのバックアップという2つの方法で、データをバックアップできます。いずれの方法にも利点と制限があるため、効果的なバックアップ計画を作成するには、それぞれの使用方法を理解することが役立ちます。

8.2.2.1 バイナリ・バックアップ

バイナリ・バックアップは、データベース・ファイルのコピーを作成するバックアップで、ファイル・システム・レベルで実行されます。バイナリ・バックアップの出力は、すべてのエントリ、索引、変更ログおよびトランザクション・ログを含む一連のバイナリ・ファイルです。バイナリ・バックアップに構成データは含まれていません。

バイナリ・バックアップは、次のいずれかのコマンドを使用して実行します。

  • dsadm backupは、オフラインで(Directory Serverインスタンスの停止中に)実行する必要があります。このコマンドは、Directory Serverインスタンスを含むローカル・サーバー上で実行してください。

  • dsconf backupは、オンラインかつDirectory Serverインスタンスに対してリモートに実行できます。

バイナリ・バックアップには、次の利点があります。

  • すべての接尾辞を同時にバックアップできます。

  • LDIFへのバックアップより、大幅に高速です。

  • レプリケーション変更ログがバックアップされます。


注意:

バイナリ・バックアップには1つの制限があります。バイナリ・バックアップからのリストアは、同じ構成のサーバーでのみ実行できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』レプリケーションでのバイナリ・コピー使用における制限事項に関する説明を参照してください。


少なくとも、一貫性のあるマシンの各セットに対して、定期的なバイナリ・バックアップを実行する必要があります。整合性のあるマシンとは、同じ構成を持つマシンのことです。


注意:

ローカル・バックアップからリストアする方がより容易であるため、各サーバー上でバイナリ・バックアップを実行してください。


この章の以降の図では、次の略称を使用します。


M = マスター・レプリカ
RA = レプリケーション承諾

次の図は、M1およびM2が同じ構成を持ち、M3およびM4が同じ構成を持つことを想定しています。この例では、M1およびM3でバイナリ・バックアップが実行されます。障害が発生した場合は、M1 (db1)のバイナリ・バックアップからM1またはM2をリストアできます。M3またはM4は、M3 (db2)のバイナリ・バックアップからリストアできます。M1およびM2は、M3のバイナリ・バックアップからはリストアできません。M3およびM4は、M1のバイナリ・バックアップからはリストアできません。

図8-2 オフラインのバイナリ・バックアップ

図8-2の説明が続きます
「図8-2 オフラインのバイナリ・バックアップ」の説明

バイナリ・バックアップのコマンドを使用する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』バイナリ・バックアップに関する説明を参照してください。

8.2.2.2 LDIFへのバックアップ

LDIFへのバックアップは、接尾辞レベルで実行されます。LDIFへのバックアップの出力は書式設定されたLDIFファイルであり、これは、接尾辞に含まれているデータをコピーしたものです。このため、このプロセスはバイナリ・バックアップよりも時間がかかります。

LDIFへのバックアップは、次のいずれかのコマンドを使用して実行します。

  • dsadm exportは、オフラインで(Directory Serverインスタンスの停止中に)実行する必要があります。このコマンドは、Directory Serverインスタンスを含むローカル・サーバー上で実行する必要があります。

  • dsconf exportは、オンラインかつDirectory Serverインスタンスに対してリモートに実行できます。


注意:

これらのコマンドを実行するときに-Qオプションを使用しないかぎり、レプリケーション情報はバックアップされます。

LDIFへのバックアップでは、dse.ldif構成ファイルがバックアップされません。以前の構成をリストアできるようにするには、このファイルを手動でバックアップしてください。


LDIFへのバックアップには、次の利点があります。

  • LDIFへのバックアップは、サーバーの構成に関係なく、任意のサーバーから実行できます。

  • LDIFバックアップからのリストアは、サーバーの構成に関係なく、任意のサーバーから実行できます。

LDIFへのバックアップには、1つの制限があります。高速なバックアップとリストアが必要な状況では、LDIFへのバックアップは実行可能になるまでに時間がかかりすぎる可能性があります。

トポロジ内の単一のマスターで、レプリケートされた接尾辞ごとに、LDIFへのバックアップを使用して定期的なバックアップを実行する必要があります。

次の図では、1つのマスター(M1)上でのみ、レプリケートされた各接尾辞に対してdsadm exportが実行されます。

図8-3 LDIFへのオフラインのバックアップ

図8-3の説明が続きます
「図8-3 LDIFへのオフラインのバックアップ」の説明

LDIFへのバックアップのコマンドを使用する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』LDIFへのバックアップに関する説明を参照してください。

8.2.3 リストア方法の選択

Directory Server Enterprise Editionでは、バイナリ・リストアおよびLDIFファイルからのリストアという2つの方法で、データをリストアできます。バックアップ方法と同様に、いずれの方法にも利点と制限があります。

8.2.3.1 バイナリ・リストア

バイナリ・リストアでは、データベース・レベルでデータがコピーされます。バイナリ・リストアは、次のいずれかのコマンドを使用して実行します。

  • dsadm restoreは、オフラインで(Directory Serverインスタンスの停止中に)実行する必要があります。このコマンドは、Directory Serverインスタンスを含むローカル・サーバー上で実行する必要があります。

  • dsconf restoreは、オンラインかつDirectory Serverインスタンスに対してリモートに実行できます。

バイナリ・リストアには、次の利点があります。

  • すべての接尾辞を同時にリストアできます。

  • レプリケーション変更ログがリストアされます。

  • LDIFファイルからのリストアより、大幅に高速です。

バイナリ・リストアには、次の制限があります。

  • リストアは、「バイナリ・バックアップ」に定義されているとおり、同じ構成のサーバー上でのみ実行できます。バイナリ・リストア機能でデータをリストアする方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』バイナリ・リストアに関する説明を参照してください。

  • データベースが破損していることに気付かずにバイナリ・バックアップを実行すると、破損したデータベースがリストアされるおそれがあります。バイナリ・バックアップでは、データベースの完全に同じコピーが作成されます。

マシンの構成が同じであり、主要な考慮事項が時間である場合、推奨されるリストア方法はバイナリ・リストアとなります。

次の図は、M1およびM2が同じ構成を持ち、M3およびM4が同じ構成を持つことを想定しています。この例では、M1 (db1)のバイナリ・バックアップからM1またはM2をリストアできます。M3またはM4は、M3 (db2)のバイナリ・バックアップからリストアできます。

図8-4 オフラインのバイナリ・リストア

図8-4の説明が続きます
「図8-4 オフラインのバイナリ・リストア」の説明

8.2.3.2 LDIFからのリストア

LDIFファイルからのリストアは、接尾辞レベルで実行されます。そのため、このプロセスはバイナリ・リストアよりも時間がかかります。LDIFからのリストアは、次のいずれかのコマンドを使用して実行できます。

  • dsadm importは、オフラインで(Directory Serverインスタンスの停止中に)実行する必要があります。このコマンドは、Directory Serverインスタンスを含むローカル・サーバー上で実行する必要があります。

  • dsconf importは、オンラインかつDirectory Serverインスタンスに対してリモートに実行できます。

LDIFファイルからのリストアには、次の利点があります。

  • このコマンドは、サーバーの構成に関係なく、任意のサーバーで実行できます。

  • レプリケーション・トポロジに関係なく、単一のLDIFファイルを使用して、ディレクトリ・サービス全体をデプロイできます。この機能は、予想されるビジネス・ニーズに合わせてディレクトリ・サービスを動的に拡張および縮小する場合に、特に有効です。

LDIFファイルからのリストアには1つの制限があります。迅速なリストアが必要な状況では、この方法は実行可能になるまでに時間がかかりすぎる場合があります。LDIFファイルからデータをリストアする方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』LDIFファイルからのデータのインポートに関する説明を参照してください。

次の図では、1つのマスター(M1)でのみ、レプリケートされた各接尾辞に対してdsadmin importが実行されます。

図8-5 LDIFからのオフラインのリストア

図8-5の説明が続きます
「図8-5 LDIFからのオフラインのリストア」の説明

8.3 ロギング方針の設計

ロギングは、個々のサーバー・レベルで管理および構成されます。ロギングは、デフォルトで有効化されていますが、デプロイメントの要件に従って再構成したり無効化できます。ロギング方針の設計は、ハードウェア要件の計画に役立ちます。詳細は、「ディレクトリ・サーバーのハードウェアのサイズ設定」を参照してください。

この項では、Directory Server Enterprise Editionのロギング機能について説明します。

8.3.1 ロギング・ポリシーの定義

トポロジ内の各Directory Serverによって、次の3つのファイルにロギング情報が格納されます。

  • アクセス・ログ。サーバーに接続したクライアントおよびリクエストされた操作がリストされます。

  • エラー・ログ。サーバー・エラーに関する情報が提供されます。

  • 監査ログ。接尾辞および構成に対する変更の詳細情報が提供されます。

トポロジ内の各Directory Proxy Serverによって、次の2つのファイルにロギング情報が格納されます。

  • アクセス・ログ。Directory Proxy Serverに接続したクライアントおよびリクエストされた操作がリストされます。

  • エラー・ログ。サーバー・エラー・メッセージが含められます。

Directory ServerおよびDirectory Proxy Serverのログ・ファイルは、次の方法で管理できます。

  • ログ・ファイル作成ポリシーの定義

  • ログ・ファイル削除ポリシーの定義

  • ログ・ファイルの手動での作成と削除

  • ログ・ファイルのアクセス権の定義

8.3.1.1 ログ・ファイル作成ポリシーの定義

ログ・ファイル作成ポリシーを使用すると、現在のログを定期的にアーカイブし、新しいログ・ファイルを開始できます。ログ・ファイル作成ポリシーは、Directory Control Centerから、またはコマンドライン・ユーティリティを使用して、Directory ServerおよびDirectory Proxy Serverに対して定義できます。

ログ・ファイル作成ポリシーを作成するときは、次の点を考慮してください。

  • 保持するログの個数

    このログ数に達すると、新しいログが作成される前に、フォルダ内の最も古いログ・ファイルが削除されます。この値が1に設定されている場合は、ログがローテーションされず、無制限に増大します。

  • 各ログ・ファイルの最大サイズ(MB単位)

    ログ・ファイルがこの最大サイズまたは次の項目で定義される最長保存期間に達すると、そのファイルはアーカイブされます。新しいログ・ファイルが開始されます。

  • 現在のログ・ファイルをアーカイブする頻度

    デフォルトは毎日です。

  • ログ・ファイルがローテーションされる時刻

    時間ベースでローテーションすると、各ログ・ファイルに同じ時間帯が記録されるため、ログ分析や傾向分析などの処理が容易になります。

また、ログ・ファイルのローテーションは、条件の組合せに基づくようにすることもできます。たとえば、ファイル・サイズが10MBを超える場合にのみ、23時30分にログをローテーションするように指定できます。

ログ・ファイル作成ポリシーを設定する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』Directory Serverのログの構成に関する説明を参照してください。

8.3.1.2 ログ・ファイル削除ポリシーの定義

ログ・ファイル削除ポリシーを使用すると、アーカイブされた古いログを自動的に削除できます。ログ・ファイル削除ポリシーは、Directory Control Centerから、またはコマンドライン・ユーティリティを使用して、Directory ServerおよびDirectory Proxy Serverに対して定義できます。ログ・ファイル作成ポリシーが定義されていない場合、ログ・ファイル削除ポリシーは適用されません。ログ・ファイルが1つ以外にない場合、ログ・ファイルの削除は機能しません。サーバーでは、ログのローテーションの時点でログ・ファイル削除ポリシーが評価および適用されます。

ログ・ファイル削除ポリシーを作成するときは、次の点を考慮してください。

  • アーカイブされるログの合計の最大サイズ

    この最大サイズに達すると、アーカイブされている最も古いログが自動的に削除されます。

  • 確保しておく最小の空きディスク領域

    空きディスク領域がこの最小値に達すると、アーカイブされている最も古いログが自動的に削除されます。

  • ログ・ファイルの最長保存期間

    ログ・ファイルがこの最長保存期間に達すると、そのログ・ファイルは自動的に削除されます。

ログ・ファイル削除ポリシーを設定する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』Directory Serverのログの構成に関する説明を参照してください。

8.3.1.3 ログ・ファイルの手動での作成と削除

手動のファイル・ローテーションおよび強制されたログ・ローテーションは、Directory Proxy Serverには適用されません。

Directory Serverに自動的な作成および削除のポリシーを定義しない場合は、ログ・ファイルを手動で作成および削除できます。また、Directory Serverには、定義されている作成ポリシーに関係なく、任意のログをただちにローテーションできるタスクが用意されています。この機能は、より詳細な調査が必要なイベントが発生した場合などに、有効であることがあります。この即時ローテーション機能を実行すると、サーバーに新しいログ・ファイルが作成されます。そのため、元のファイルにはサーバーからログが追加されない状態となり、そのファイルを調査できます。

ログを手動でローテーションする方法およびログ・ローテーションを強制する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』Directory Serverログの手動ローテーションに関する説明を参照してください。

8.3.1.4 ログ・ファイルに対する権限の定義

Directory Server 5.2では、ディレクトリ・マネージャのみがログ・ファイルを読み取ることができました。Directory Server Enterprise Editionでは、ログ・ファイルを作成する場合に使用する権限をサーバー管理者が定義できます。ログ・ファイルの権限を定義する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』Directory Serverのログの構成に関する説明を参照してください。

8.4 監視方針の設計

デプロイメントを成功させるには、効果的な監視とイベント管理の方針が必要です。このような方針では、監視対象のイベント、使用するツールおよびイベントが発生した場合に実行するアクションを定義します。よく発生するイベントに対して計画しておくと、サービスの停止やサービス・レベル低下の可能性を回避できます。この方針によって、ディレクトリ・サービスの可用性と品質が向上します。

監視方針を設計するには、次のことを実行します。

8.4.1 Directory Server Enterprise Editionで提供される監視ツール

この項では、Directory Server Enterprise Editionで使用できる監視ツールや、サーバー・アクティビティの監視に使用できるその他のツールの概要について説明します。

「監視領域の特定」で説明されている監視領域は、これらのツールの1つ以上を使用して監視できます。

  • コマンドライン・ツール。ディスク使用率などのパフォーマンスを監視するオペレーティング・システムに固有のツール、ディレクトリに格納されているサーバー統計を収集するldapsearchなどのLDAPツール、サード・パーティ製ツール、カスタム・シェル、Perlスクリプトが含まれます。

  • Directory ServerおよびDirectory Proxy Serverのログ。アクセス・ログ、監査ログおよびエラー・ログが含まれます。これらのログを手動で監視したり、カスタム・スクリプトを使用して解析すると、デプロイメントに関連する監視情報を抽出できます。Directory Server Resource Kitには、アクセス・ログを解析できるログ・アナライザ・ツール、logconvが備えられています。ログ・アナライザ・ツールによって、使用状況統計が抽出され、重要なイベントの発生回数が集計されます。このツールの詳細は、logconvを参照してください。ログファイルを表示および構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第14章「Directory Serverのロギング」を参照してください。

  • Directory Service Control Center (DSCC)。ディレクトリ操作をリアルタイムに監視できるグラフィカル・ユーザー・インタフェースです。DSCCによって、リソース・サマリー、現在のリソース使用率、接続状態およびグローバル・データベース・キャッシュ情報など、一般的なサーバー情報が提供されます。また、データベースのタイプ、ステータスおよびエントリ・キャッシュ統計など、一般的なデータベース情報も提供されます。データベースのキャッシュ情報および各索引ファイルに関連する情報も提供されます。さらに、DSCCには、接続およびそれぞれの連鎖する接尾辞で実行される操作に関する情報も表示されます。

  • レプリケーション監視ツール。コマンドライン・ツール、repldiscinsyncおよびentrycmpが含まれます。

    これらのツールを使用すると、次のことを実行できます。

    • マスター・レプリカと1つ以上のコンシューマ・レプリカ間の同期状態の監視

    • 2つ以上の異なるレプリカで同じエントリを比較し、レプリケーション・ステータスの評価

    • 複雑なディレクトリ・デプロイメントを扱う場合に特に有効な、レプリケーション・トポロジ全体の表示

    詳細は、repldiscinsyncおよびentrycmpを参照してください。

    DSCCを使用して、レプリケーション・ステータスを監視することもできます。レプリケーションを監視する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』レプリケーション・ステータスの取得に関する説明を参照してください

  • Simple Network Management Protocol (SNMP)。グローバルなネットワークの制御と監視のための標準メカニズムであり、ネットワーク管理者がネットワーク監視アクティビティを一元的に実行できます。

    SNMPエージェントを使用した監視の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第15章「Directory Serverの監視」を参照してください。

8.4.2 監視領域の特定

監視する対象や、その対象をどの程度監視するかは、具体的なデプロイメントによって異なります。ただし、一般的に、監視方針には次のものが含まれます。

  • リソース使用率、サーバー・ステータス、接続情報などのサーバー・アクティビティ

  • キャッシュ、トランザクション、ロック、ログ情報などのデータベース・アクティビティ

  • 使用可能なディスク領域やしきい値情報などのディスク・ステータス

  • ステータス(レプリケーションが実行中かどうか)や同期の状態などのレプリケーション・アクティビティ

  • 索引を使用しない検索、検索フィルタ、よく使用される索引などの索引付けの効率

  • 失敗したバインド試行、オープン接続数、実効権限などのセキュリティ・ステータス