test

Sun Java System Directory Server Enterprise Edition 6.0 配備計画ガイド

第 8 章 管理と監視の要件の特定

Directory Server Enterprise Edition の管理は、以前のバージョンの Directory Server から大幅に変更されています。これらの変更は、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』で詳細に説明されています。

この章では、これらの変更の概要を示したあと、配備の計画段階で行う必要のある管理上の決定について説明します。

Directory Server Enterprise Edition の管理モデル

Directory Server Enterprise Edition では、管理者がインスタンスの作成や管理をより細かく制御できるようになりました。この制御は、2 つの新しいコマンド dsadm と dsconf を使用して実現されます。これらのコマンドは、以前の directoryserver コマンドで提供されていたすべての機能に加え、追加の機能を提供します。

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

新しい管理モデルでは、Directory Server インスタンスの 「ServerRoot」への関連付けはなくなりました。各 Directory Server インスタンスは、通常のスタンドアロンディレクトリと同じ方法で操作できるスタンドアロンディレクトリです。

dsconf は、cn=config への書き込みアクセスが必要な管理操作を行います。dsconf コマンドは、LDAP クライアントです。アクティブな Directory Server インスタンス上でのみ実行できます。このコマンドはリモートから実行することができ、それによって、管理者は複数のインスタンスを単一のリモートマシンから設定できます。

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

これらのコマンド行ユーティリティーに加えて、Directory Server Enterprise Edition は Java Web コンソールにも統合されています。このコンソールを使用すると、Directory Server Enterprise Edition やその他の Sun 製品を集中管理のユーザーインタフェースから管理できます。Directory Service Control Center (DSCC) は、Directory Server と Directory Proxy Server の管理専用に用意された、Java Web コンソールのサービスです。DSCC は、コマンド行ユーティリティーと同じ機能のほか、複数のサーバーを一度に設定できるウィザードを提供しています。DSCC はまた、レプリケーショントポロジをグラフィカルに監視できる、レプリケーショントポロジの描画ツールも提供します。このツールでは、個々のマスター、ハブ、コンシューマや、それらの間のレプリケーションアグリーメントがリアルタイムに表示されるため、レプリケーションの監視が簡略化されます。

リモート管理

前の節で説明した Directory Server Enterprise Edition の管理モデルでは、トポロジ内の任意の Directory Server または Directory Proxy Server のリモート管理を行うこともできます。サーバーは、コマンド行ユーティリティーと Java Web コンソールの両方を使用して、リモートから管理できます。

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

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

次の図は、新しい管理モデルによるリモート管理の容易性を示しています。この図は、コンソールコマンドや設定コマンドを Directory Server および Directory Proxy Server インスタンスからリモートにインストールして実行できることを示しています。管理コマンドは、これらのインスタンスに対してローカルに実行する必要があります。

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

図は、管理コマンドと設定コマンド、および Directory Control Center を含む新しい管理モデルを示しています。

バックアップと復元のポリシーの設計

データ破壊やデータ損失をともなう障害の状況では、データの最新のバックアップを保有していることが不可欠です。できるだけ、ほかのサーバーからのサーバーの再初期化は避けてください。データのバックアップ方法については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の第 8 章「Directory Server のバックアップと復元」を参照してください。

ここでは、バックアップと復元の戦略を計画する上で考慮すべき事項の概要について説明します。

高レベルのバックアップと復旧の原則

バックアップ戦略を設計するときは、次の高レベルの原則を適用します。

バックアップ方法の選択

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

バイナリバックアップ

バイナリバックアップは、データベースファイルのコピーを生成するものであり、ファイルシステムレベルで実行されます。バイナリバックアップの出力は、すべてのエントリ、インデックス、更新履歴ログ、トランザクションログを含むバイナリファイルのセットです。バイナリバックアップには、設定データは含まれません。

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

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

バイナリバックアップには、1 つの制限があります。バイナリバックアップからの復元は、「同一の」設定のサーバーだけでしか実行できません。

この制限は次を意味します。

少なくとも、整合性のあるマシンの各セットに対して定期的なバイナリバックアップを実行してください。整合性のあるマシンとは、前述のように同一の設定を持つマシンのことです。

注 –

ローカルバックアップからの復元の方が簡単なため、各サーバーでバイナリバックアップを実行してください。

この章の残りの図では、次の略語を使用します。

M = マスターレプリカ 

RA = レプリケーションアグリーメント 

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 と M3 でバイナリバックアップが行われます。障害が発生した場合は、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。M1 と M2 を M3 のバイナリバックアップから復元することはできません。M3 と M4 を M1 のバイナリバックアップから復元することはできません。

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

2 つのサーバーから 2 つの個別のデータベースへのオフラインのバイナリバックアップ

バイナリバックアップのコマンドの使用方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「バイナリバックアップ」を参照してください。

LDIF へのバックアップ

LDIF へのバックアップはサフィックスレベルで行われます。LDIF へのバックアップの出力は、サフィックスに含まれているデータのコピーである、フォーマットされた LDIF ファイルです。このため、このプロセスはバイナリバックアップと比較して時間がかかります。

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

注 –

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

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

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

LDIF へのバックアップには、1 つの制限があります。迅速なバックアップと復元が必要な状況では、LDIF へのバックアップでは時間がかかり過ぎる可能性があります。

トポロジの単一マスターで、レプリケートされた各サフィックスを LDIF に定期的にバックアップする必要があります。

次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadm export が実行されています。

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

dsadm export を使用したバックアップ

LDIF へのバックアップのコマンドの使用方法については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「LDIF へのバックアップ」を参照してください。

復元方法の選択

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

バイナリ復元

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

バイナリ復元には、次のような利点があります。

バイナリ復元には、次のような制限があります。

マシンの設定が同一であり、実行時間を極力減らすことを一番の目的としている場合は、推奨される復元方法はバイナリ復元になります。

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。

図 8–4 オフラインのバイナリ復元

2 つの個別のデータベースから 2 つの個別のサーバーへのバイナリ復元

LDIF からの復元

LDIF ファイルからの復元は、サフィックスレベルで実行されます。このため、このプロセスはバイナリ復元と比較して時間がかかります。LDIF からの復元は、次のいずれかのコマンドを使用して実行できます。

LDIF ファイルからの復元には、次のような利点があります。

LDIF ファイルからの復元には、1 つの制限があります。迅速な復元が必要な状況では、この方法は時間がかかり過ぎる場合があります。LDIF ファイルからのデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「LDIF ファイルからのデータのインポート」を参照してください。

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

図 8–5 LDIF からのオフラインの復元

dsadm import を使用した、LDIF ファイルからのオフラインの復元

ロギング方法の設計

ロギングは、個別のサーバーレベルで管理および設定されます。ロギングは、デフォルトで有効になっていますが、配備の要件に従って再設定したり無効にしたりすることができます。ロギング方法の設計は、ハードウェア要件の計画に役立ちます。詳細については、「Directory Server のハードウェアサイジング」を参照してください。

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

ロギングポリシーの定義

トポロジ内の各 Directory Server は、ロギング情報を次の 3 つのファイルに格納します。

トポロジ内の各 Directory Proxy Server は、ロギング情報を次の 2 つのファイルに格納します。

Directory Server と Directory Proxy Server の両方のログファイルを次の方法で管理できます。

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

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

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

ログファイルのローテーションを、条件の組み合わせに基づいて行うこともできます。たとえば、ファイルサイズが 10M バイトより大きい場合に「のみ」、23 時 30 分にログをローテーションするように指定できます。

ログファイル作成ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「Directory Server のログの設定」を参照してください。

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

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

ログファイル削除ポリシーを定義する場合は、次の点を考慮してください。

ログファイル削除ポリシーを設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「Directory Server のログの設定」を参照してください。

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

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

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

ログを手動でローテーションする方法、およびログのローテーションを強制する方法については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「Directory Server ログの手動でのローテーション」を参照してください。

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

以前のバージョンの Directory Server では、ログファイルを読み取れるのはディレクトリマネージャーだけでした。Directory Server Enterprise Edition では、ログファイルの作成時にアクセス権をサーバー管理者が定義できます。ログファイルのアクセス権を定義する方法については、『Sun Java System Directory Server Enterprise Edition 6.0 管理ガイド』の「Directory Server のログの設定」を参照してください。

監視戦略の設計

配備を成功させるには、効果的な監視とイベント管理の戦略が必要です。この戦略は、監視対象となるイベント、使用するツール、そのイベントが発生した場合に実行するアクションを定義します。発生しがちなイベントに対する計画を立てておけば、サービスの停止やレベル低下の可能性を防止できます。この戦略によって、ディレクトリのサービスの可用性と品質が向上します。

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

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

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

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

監視領域の特定

監視する対象や、その対象をどの程度監視するかは、具体的な配備によって異なります。ただし、一般に、監視戦略には次の要素が含まれます。

Directory Editor を使用したデータ管理

Directory Server Enterprise Edition の Directory Editor コンポーネントは、Web ブラウザを使用してディレクトリデータを管理できる Java Web アプリケーションです。Directory Editor を使用すると、すべてのユーザーが、クライアントソフトウェアをインストールしなくてもディレクトリデータにリモートアクセスできます。

Directory Editor は、次の機能を提供します。

Directory Editor のインストール、設定、および使用の詳細については、Directory Editor マニュアル コレクションを参照してください。

ディレクトリエントリのグループ化と属性の管理

ディレクトリ情報ツリーは、エントリを階層構造で構成します。この階層は、グループ化メカニズムの 1 種です。この階層は、分散しているエントリの関連付け、頻繁に変更される組織、または多数のエントリで繰り返されるデータには適していません。Directory Server のグループとロールは、エントリ間のより柔軟な関連付けを提供します。サービスクラス (CoS) のメカニズムを使用すると、属性がエントリ間で共有されるように各属性を管理できます。この共有は、アプリケーションには見えない方法で実行されます。

これらのエントリのグループ化と属性管理のメカニズムは、『Sun Java System Directory Server Enterprise Edition 6.0 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.0 Reference』の第 9 章「Directory Server Class of Service」で詳細に説明されています。

ここでは、管理戦略の設計には十分なグループ化メカニズムの概要について説明します。ただし、このメカニズムの動作の仕組みや、それらの設定方法については説明していません。

この節は、次の項目で構成されています。

スタティックグループとダイナミックグループ

Directory Server は、次の 2 種類のグループを識別します。

管理されているロール、フィルタを適用したロール、入れ子のロール

ロールは、エントリのグループ化メカニズムです。ロールを使用すると、エントリがディレクトリから取得されるとすぐに、ロールのメンバーシップを決定できます。各ロールはメンバー (そのロールを所有するエントリ) を持ちます。グループと同じようにロールのメンバーを明示的またはダイナミックに指定できます。

Directory Server は、次の 3 種類のロールをサポートしています。

グループとロールのどちらを使用するかの決定

グループとロールのメカニズムは、一部の機能が重なっています。どちらのメカニズムにも利点と欠点があります。一般に、ロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムはサーバーの複雑さに影響を及ぼし、グループ化メカニズムを選択することで、クライアントがどのようにメンバー情報を処理するかが決まるため、グループ化メカニズムは慎重に計画する必要があります。どちらのメカニズムがより適しているかを判断するには、実行する標準的なメンバーシップクエリーと管理操作を理解してください。

グループメカニズムの利点

グループには、次の利点があります。

ロールメカニズムの利点

ロールには、次の利点があります。

ロールに対するアクセス権の制限

ロールを使用する場合は、次の問題に注意してください。

サービスクラスによる属性の管理

サービスクラス (CoS) メカニズムを使用すると、エントリ間で属性を共有できます。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。CoS はメンバーを定義しませんが、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。CoS の値は、それらの値が要求されたときに動的に計算されます。CoS 機能や、CoS のさまざまな種類については、『Sun Java System Directory Server Enterprise Edition 6.0 Reference』で詳細に説明されています。

以降の節では、パフォーマンスの低下を回避しながら、CoS 機能を意図したとおりに使用する方法について詳しく説明します。

注 –

CoS の生成は、常にパフォーマンスに影響します。実際に必要とするより多くの属性を検索するクライアントアプリケーションによって、この問題がさらに悪化する可能性があります。

クライアントアプリケーションの記述方法を指示できる場合は、実際に必要な属性値のみを検索するようにクライアントアプリケーションを記述することで、パフォーマンスの大幅な向上が期待できることを開発者に伝えてください。

多数のエントリが同じ値を共有する場合の CoS の使用

CoS は、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。

たとえば、ou=People の下のすべてのユーザーエントリに companyName 属性が含まれている、MyCompany, Inc. のディレクトリを考えてみます。請負業者のエントリには companyName 属性に直接値がセットされていますが、すべての正社員の companyName には、CoS で生成された値 MyCompany, Inc. がセットされています。次の図は、この例でポインタ CoS を使用した場合を示しています。CoS によって、すべての正社員の companyName 値が生成されるが、請負業者の従業員用に直接設定されている実際の companyName 値は置き換えられないことに注意してください。会社名は、companyName が許可された属性になっているエントリに対してのみ生成されます。

図 8–6 ポインタ CoS を使用した CompanyName の生成

図は、ポインタ CoS を使用して生成された CompanyName 属性を示しています。

多数のエントリが同じ値を共有する場合は、ポインタ CoS が特にうまく機能します。正社員に対する companyName の管理が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー (DIT) は、一般的な特性を共有するエントリをまとめる傾向があります。深い DIT でポインタ CoS を使用すると、ツリー内の適切な分岐に CoS 定義を配置することによって、一般的な属性値を生成できます。

エントリが自然な関係を持っている場合の CoS の使用

CoS はまた、ディレクトリデータが自然な関係を持っている場合も、データ管理の大きな利点を提供します。

すべての従業員にマネージャーがいる企業ディレクトリを考えてみます。すべての従業員がメールストップと Fax 番号を、もっとも近い管理アシスタントと共有しています。図 8–7 は、間接 CoS を使用して、マネージャーのエントリから部門番号を取得する様子を示しています。図 8–8 では、メールストップと Fax 番号が管理アシスタントのエントリから取得されています。

図 8–7 間接 CoS を使用した DepartmentNumber の生成

図は、間接 CoS を使用して生成された DepartmentNumber 属性を示しています。

この実装では、マネージャーのエントリに departmentNumber の実際の値が含まれ、生成されているどの値よりもこの実際の値が優先されます。Directory Server は、CoS で生成された属性値からは属性値を生成しません。そのため、図 8–7 の例では、部門番号の属性値をマネージャーのエントリ上でのみ管理する必要があります。同様に、図 8–8 に示されている例では、メールストップと Fax 番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。

図 8–8 間接 CoS を使用したメールストップと Fax 番号の生成

図は、間接 CoS を使用して生成されたメールストップと Fax 番号の属性を示しています。

単一の CoS 定義エントリを使用して、このような関係をディレクトリ内のさまざまなエントリに利用できます。

別の自然な関係に、サービスレベルがあります。顧客にスタンダード、シルバー、ゴールド、およびプラチナのパッケージを提供しているインターネットサービスプロバイダを考えてみます。顧客のディスク割り当て、メールボックスの数、前払いのサポートレベルに対する権限などは、購入したサービスレベルによって異なります。次の図は、クラシック CoS スキーマによってこの機能が可能になるようすを示しています。

図 8–9 クラシック CoS を使用したサービスレベルデータの生成

図は、クラシック CoS を使用して生成されたサービスレベルデータを示しています。

1 つの CoS 定義が複数の CoS テンプレートエントリに関連付けられる場合があります。

過剰な CoS 定義の回避

Directory Server は、1 つのクラシック CoS 定義エントリが複数の CoS テンプレートエントリに関連付けられている場合は CoS を最適化します。Directory Server は、多数の CoS 定義が適用される可能性がある場合は CoS を最適化しません。代わりに、Directory Server は各 CoS 定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千の CoS 定義が存在する場合はパフォーマンスの問題が発生します。

この状況は、図 8–9 で示した例を変更することで発生する可能性があります。顧客に、各顧客のサービスレベルの委任管理を提供しているインターネットサービスプロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールド、およびプラチナのサービスレベルの定義エントリが提供されます。顧客数が 1000 に増えると、1000 個のクラシック CoS 定義が作成されることになります。どの定義が適用されるを判定するために 1000 個の CoS 定義のリストがチェックされるため、Directory Server のパフォーマンスが影響を受ける可能性があります。この種の状況で CoS を使用する必要がある場合は、間接 CoS を検討してください。間接 CoS では、顧客のエントリによって、その顧客のサービスクラス割り当てを定義するエントリが特定されます。

1 つまたは 2 つのターゲットエントリごとに別の CoS スキーマを選択することの限界に近づき始めたら、実際の値を更新することをお勧めします。CoS で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。