Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド

11g リリース1 (11.1.1.7.0)

B72436-01(原本部品番号:E28974-01)

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- このドキュメントをお読みになる前に

- このドキュメントの構成

- このドキュメントで使用する例

- Oracle Directory Server Enterprise Editionドキュメント・セット

- 関連ドキュメント

- 再配布可能ファイル

- デフォルト・パスとコマンドの場所

- 表記規則

- コマンド例でのシェル・プロンプト

- 記号の表記規則

- ドキュメント、サポートおよびトレーニング

- Oracleソフトウェア・リソース

- ドキュメントのアクセシビリティについて

第I部 デプロイメント計画の概要

1 Directory Server Enterprise Editionのデプロイメント計画の概要

- 1.1 デプロイメント計画について

- 1.1.1 デプロイメントのDirectory Server Enterprise Editionコンポーネント

- 1.2 ソリューション・ライフ・サイクル

2 Directory Server Enterprise Editionのビジネス分析

- 2.1 ビジネス分析について

- 2.2 Directory Server Enterprise Editionのビジネス要件の定義

第II部 技術要件

3 Directory Server Enterprise Editionの使用状況分析

- 3.1 使用状況分析の要素

4 データ特性の定義

- 4.1 データソースと所有者の決定

- 4.1.1 データソースの特定

- 4.1.2 データ所有者の決定

- 4.1.3 ユーザー・データと構成データの区別

- 4.2 異種データソースからのデータの特定

- 4.3 DITの設計

- 4.3.1 接尾辞の選択

- 4.3.2 DIT構造の作成とエントリのネーミング

- 4.3.2.1 ブランチ・ポイントとネーミングに関する考慮事項

- 4.3.2.2 レプリケーションに関する考慮事項

- 4.3.2.3 アクセス制御に関する考慮事項

- 4.4 ディレクトリ・スキーマの設計

- 4.4.1 スキーマ設計プロセス

- 4.4.2 データの一貫性の維持

- 4.5 その他のディレクトリ・データ・リソース

5 サービス・レベル合意の定義

- 5.1 システム品質の特定

- 5.2 パフォーマンス要件の定義

- 5.2.1 クライアント・アプリケーションの特定

- 5.2.2 ディレクトリ・エントリの数とサイズの特定

- 5.2.3 読取り数の特定

- 5.2.4 書込み数の特定

- 5.2.5 許容できるレスポンス時間の見積り

- 5.2.6 許容できるレプリケーション待機時間の見積り

- 5.3 可用性要件の定義

- 5.4 スケーラビリティ要件の定義

- 5.5 セキュリティ要件の定義

- 5.6 潜在処理能力要件の定義

- 5.7 運用性要件の定義

6 システムの特性のチューニングおよびハードウェアのサイズ設定

- 6.1 ホスト・システムの特性

- 6.2 ポート番号

- 6.2.1 Directory ServerおよびDirectory Proxy ServerのLDAPおよびLDAPSポート番号

- 6.2.2 Directory ServerのDSMLポート番号

- 6.2.3 Directory Service Control CenterおよびDSCCエージェントのポート番号

- 6.2.4 Identity Synchronization for Windowsのポート番号

- 6.3 Directory Service Control Centerのハードウェアのサイズ設定

- 6.4 Directory Proxy Serverのハードウェアのサイズ設定

- 6.4.1 仮想メモリーの構成

- 6.4.2 ワーカー・スレッドおよびバックエンド接続の構成

- 6.4.3 Directory Proxy Serverのディスク領域

- 6.4.4 Directory Proxy Serverのネットワーク接続

- 6.5 Directory Serverのハードウェアのサイズ設定

- 6.5.1 チューニング・プロセス

- 6.5.2 サンプル・ディレクトリ・データの作成

- 6.5.3 構成する項目とその理由

- 6.5.3.1 Directory Serverのデータベース・ページ・サイズ

- 6.5.3.2 Directory Serverのキャッシュ・サイズ

- 6.5.3.3 Directory Serverの索引作成

- 6.5.3.4 Directory Serverの管理ファイル

- 6.5.3.5 Directory Serverのレプリケーション

- 6.5.3.6 Directory Serverのスレッドおよびファイル記述子

- 6.5.3.7 Directory Serverの規模の増大

- 6.5.3.8 最重要のチューニング・ヒント

- 6.5.4 クライアント・アプリケーション負荷のシミュレーション

- 6.5.5 Directory Serverとプロセッサ

- 6.5.6 Directory Serverとメモリー

- 6.5.7 Directory Serverとローカル・ディスク領域

- 6.5.8 Directory Serverとネットワーク接続性

- 6.5.9 クライアントが使用可能なDirectory Serverリソースの制限

- 6.5.10 Directory Serverにより使用されるシステム・リソースの制限

- 6.6 Directory Server用のオペレーティング・システムのチューニング

- 6.6.1 オペレーティング・システムのバージョンとパッチのサポート

- 6.6.2 基本的なセキュリティ・チェック

- 6.6.3 正確なシステム・クロック時間

- 6.6.4 システム・リブート時の再起動

- 6.6.5 idsktuneコマンドによるシステム固有のチューニング

- 6.6.5.1 ファイル記述子の設定

- 6.6.5.2 伝送制御プロトコル(TCP)の設定

- 6.7 Directory Serverの物理的機能

- 6.8 全体的なパフォーマンスを改善するためのその他のヒント

- 6.9 キャッシュ設定のチューニング

- 6.9.1 基本的なチューニング推奨事項

- 6.9.1.1 検索速度の最大化(検索のみ)

- 6.9.1.2 変更速度の最大化(変更のみ)

- 6.9.2 小規模、中規模および大規模なデータ・セット

- 6.9.3 最適な検索パフォーマンス(検索のみ)

- 6.9.4 最適な変更パフォーマンス(変更のみ)

- 6.10 パフォーマンスのための索引のチューニング

- 6.11 基本的なDirectory Serverのサイズ設定の例: ディスクおよびメモリー要件

- 6.11.1 システムの特性

- 6.11.2 Directory Serverインスタンスの準備

- 6.11.3 10,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

- 6.11.4 100,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

- 6.11.5 1,000,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

- 6.11.6 結果のサマリー

7 セキュリティ要件の特定

- 7.1 セキュリティの脅威

- 7.2 セキュリティ方式の概要

- 7.3 認証方式の決定

- 7.3.1 匿名アクセス

- 7.3.2 簡易パスワード認証

- 7.3.3 セキュア接続での簡易パスワード認証

- 7.3.4 証明書ベースのクライアント認証

- 7.3.5 SASLベースのクライアント認証

- 7.3.6 アカウントの非アクティブ化による認証の防止

- 7.3.7 グローバル・アカウント・ロックアウトを使用した認証の防止

- 7.3.8 外部認証のマッピングおよびサービス

- 7.4 プロキシ認可

- 7.5 パスワード・ポリシーの設計

- 7.5.1 パスワード・ポリシーのオプション

- 7.5.2 レプリケーション環境でのパスワード・ポリシー

- 7.5.3 パスワード・ポリシーの移行

- 7.6 Windowsとのパスワードの同期

- 7.7 暗号化方式の決定

- 7.7.1 SSLによる接続の保護

- 7.7.2 保存された属性の暗号化

- 7.7.2.1 属性の暗号化とは

- 7.7.2.2 属性の暗号化の実装

- 7.7.2.3 属性の暗号化とパフォーマンス

- 7.8 ACIによるアクセス制御の設計

- 7.8.1 デフォルトACI

- 7.8.2 ACIの対象範囲

- 7.8.3 実効権限情報の取得

- 7.8.4 ACIの使用上のヒント

- 7.9 接続ルールによるアクセス制御の設計

- 7.10 Directory Proxy Serverによるアクセス制御の設計

- 7.10.1 接続ハンドラの動作

- 7.11 エントリの安全なグループ化

- 7.11.1 ロールの安全な使用方法

- 7.11.2 CoSの安全な使用方法

- 7.12 ファイアウォールの使用

- 7.13 root以外として実行

- 7.14 その他のセキュリティ・リソース

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

- 8.1 ODSEE管理モデルの概要

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

- 8.1.2 Directory Service Control Center (DSCC)

- 8.1.2.1 DSCC Webインタフェース

- 8.1.2.2 DSCCエージェント

- 8.1.2.3 DSCCレジストリ

- 8.1.3 リモート管理

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

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

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

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

- 8.2.2.2 LDIFへのバックアップ

- 8.2.3 リストア方法の選択

- 8.2.3.1 バイナリ・リストア

- 8.2.3.2 LDIFからのリストア

- 8.3 ロギング方針の設計

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

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

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

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

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

- 8.4 監視方針の設計

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

- 8.4.2 監視領域の特定

第III部 論理設計

9 基本的なデプロイメントの設計

- 9.1 基本的なデプロイメントのアーキテクチャ

- 9.2 基本的なデプロイメントの設定

- 9.3 基本的なデプロイメントのパフォーマンスの改善

- 9.3.1 索引作成による検索の高速化

- 9.3.2 検索パフォーマンスのためのキャッシュの最適化

- 9.3.2.1 すべてのエントリと索引がメモリーに収まる場合

- 9.3.2.2 32ビットDirectory Serverのため十分なメモリーがある場合

- 9.3.2.3 メモリー不足

- 9.3.3 書込みパフォーマンスのためのキャッシュの最適化

10 スケーラビリティを持つデプロイメントの設計

- 10.1 読取りスケーラビリティのためのロード・バランシングの使用

- 10.1.1 ロード・バランシングのためのレプリケーションの使用

- 10.1.1.1 基本的なレプリケーション概念

- 10.1.1.2 初期レプリケーション要件の評価

- 10.1.1.3 単一のデータ・センターにおけるマルチマスター・レプリケーションを使用したロード・バランシング

- 10.1.1.4 大規模デプロイメントにおけるレプリケーションを使用したロード・バランシング

- 10.1.1.5 サーバー・グループを使用したマルチマスター・トポロジの簡略化

- 10.1.2 ロード・バランシングのためのDirectory Proxy Serverの使用

- 10.2 書込みスケーラビリティのための分散の使用

- 10.2.1 複数のデータベースの使用

- 10.2.2 分散のためのDirectory Proxy Serverの使用

- 10.2.2.1 DITに基づくルーティング

- 10.2.2.2 カスタム・アルゴリズムに基づくルーティング

- 10.2.3 Directory Proxy Serverを使用したバインドDNに基づくリクエストの分散

- 10.3 DITの下位へのデータ分散

- 10.3.1 分散データの論理ビュー

- 10.3.2 データ記憶域の物理ビュー

- 10.3.3 サンプル分散シナリオのDirectory Server構成

- 10.3.4 サンプル分散シナリオのDirectory Proxy Server構成

- 10.3.5 データ増大の考慮事項

- 10.4 分散のためのリフェラルの使用

- 10.4.1 リフェラルを使用したDirectory Proxy Serverの使用

11 グローバル・デプロイメントの設計

- 11.1 複数のデータ・センターをまたぐレプリケーションの使用

- 11.1.1 マルチマスター・レプリケーション

- 11.1.1.1 マルチマスター・レプリケーションの概要

- 11.1.1.2 WAN経由のマルチマスター・レプリケーション

- 11.1.1.3 フル・メッシュのマルチマスター・トポロジ

- 11.1.2 カスケード型レプリケーション

- 11.1.3 優先順位付きレプリケーション

- 11.1.4 部分レプリケーション

- 11.1.5 国際的な企業のレプリケーション方針の例

- 11.2 グローバル・デプロイメントでのDirectory Proxy Serverの使用

- 11.2.1 グローバル企業の分散方針の例

12 高可用性デプロイメントの設計

- 12.1 可用性とシングル・ポイント障害

- 12.1.1 SPOFの軽減

- 12.1.1.1 冗長性の長所と短所

- 12.1.1.2 冗長性によるSPOFの処理方法

- 12.1.1.3 ハードウェア・レベルの冗長性

- 12.1.1.4 ソフトウェア・レベルの冗長性

- 12.2 高可用性のためのレプリケーションおよび冗長性の使用

- 12.2.1 冗長レプリケーション承諾の使用

- 12.2.2 レプリカの昇格と降格

- 12.2.3 冗長ソリューションの一部としてのDirectory Proxy Serverの使用

- 12.2.4 高可用性のためのアプリケーション分離の使用

- 12.2.5 高可用性のために冗長性を使用するサンプル・トポロジ

- 12.2.5.1 単一のデータ・センターにおける可用性を確保するためのレプリケーションの使用

- 12.2.5.2 2つのデータ・センターにわたる可用性のためのレプリケーションの使用

- 12.2.5.3 複数のDirectory Proxy Serverの使用

- 12.2.5.4 アプリケーション分離の使用

第IV部 高度なデプロイメント

13 SolarisでのLDAPベースのネーミングの使用

- 13.1 LDAPベースのネーミング・サービスを使用する理由

- 13.2 NISからLDAPへの移行

- 13.3 NIS+からLDAPへの移行

14 仮想ディレクトリのデプロイ

- 14.1 仮想ディレクトリを使用するタイミング

- 14.2 一般的な仮想ディレクトリ・シナリオ

- 14.2.1 異なるデータ・ソースのユーザー・アイデンティティの結合

15 同期データを含むデプロイメントの設計

- 15.1 Identity Synchronization for Windowsデプロイメントの考慮事項

索引

図一覧

- 1-1 Directory Server Enterprise Editionコンポーネント

- 1-2 ソリューション・ライフ・サイクル

- 6-1 検索パフォーマンス

- 6-2 変更パフォーマンス

- 7-1 属性の暗号化のロジック

- 7-2 Directory Proxy Serverの接続ハンドラのロジック

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

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

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

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

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

- 9-1 単一のマシン上の基本的なDirectory Server Enterprise Editionのアーキテクチャ

- 9-2 リモートのDirectory Service Control Centerを使用した基本的なDirectory Server Enterprise Editionのアーキテクチャ

- 10-1 レプリケーション・トポロジにおけるレプリカの役割

- 10-2 ロード・バランシングのためのマルチサーバー・レプリケーションの使用

- 10-3 大規模デプロイメントにおけるロード・バランシングのためのマルチサーバー・レプリケーションの使用

- 10-4 マルチマスター・トポロジ内のサーバー・グループ

- 10-5 スケーラビリティを持つデプロイメントにおける比例および操作ベース・ロード・バランシングの使用

- 10-6 3つのサブ接尾辞を含むディレクトリ・ツリー

- 10-7 3つの異なるデータベースに格納された3つのサブ接尾辞

- 10-8 2つの異なるサーバーに格納された3つのデータベース

- 10-9 Directory Proxy Serverを使用したバインドDNに基づくリクエストのルーティング

- 10-10 分散データの論理ビュー

- 10-11 データ記憶域の物理ビュー

- 10-12 Directory Server構成

- 10-13 Directory Proxy Server構成

- 10-14 リフェラルを使用した特定サーバーへのクライアントの誘導

- 10-15 リフェラルを使用したDirectory Proxy Serverの使用

- 11-1 マルチマスター・レプリケーション構成(2つのマスター)

- 11-2 フル・メッシュの4方向マルチマスター・レプリケーション構成

- 11-3 マスターAのレプリケーション構成(フル・メッシュのトポロジ)

- 11-4 コンシューマ・サーバーEのレプリケーション構成(フル・メッシュのトポロジ)

- 11-5 カスケード型レプリケーション構成

- 11-6 数多くのコンシューマに対するカスケード型レプリケーション

- 11-7 2つのデータ・センターでのロード・バランシングのためのマルチマスター・レプリケーションの使用

- 11-8 分散ディレクトリ・インフラストラクチャ

- 12-1 単一のデータ・センターにおけるマルチマスター・レプリケーション

- 12-2 単一のデータ・センターのサンプル・リカバリ手順

- 12-3 2つのデータ・センターにおけるリカバリ・レプリケーション承諾

- 12-4 内部の高可用性構成

- 12-5 スケーラビリティを持つデプロイメントにおけるアプリケーション分離の使用

- 14-1 複数リポジトリからの集約データの仮想ビュー

表一覧

- 4-1 従来のDNブランチ・ポイントの属性

- 6-1 クライアント・アプリケーション専用のリソースに関するチューニング推奨事項

- 6-2 システム・リソースに関するチューニング推奨事項

- 6-3 サイズ設定サマリー

- 9-1 様々なディスクにおけるデータベースとログの分離

- 12-1 単一のデータ・センターの障害マトリックス

Oracle® Fusion Middleware

Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド

11g リリース1 (11.1.1.7.0)

B72436-01(原本部品番号:E28974-01)

2013年1月

Oracle Directory Server Enterprise Editionのデプロイメントの計画について説明します。

Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0)

B72436-01

Copyright © 2001, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者: Gina Cariaga

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』には、ディレクトリ・サービス・デプロイメントの計画に必要な情報が含まれています。このガイドでは、データ型、アクセス制御、サイズ設定などの問題に関して、初期に決定する必要がある事項について説明しています。企業の特定の要件に使用できる概略レベルの例および戦略も提供します。

対象読者

このガイドの主な対象読者は、ディレクトリ・サービス・デプロイメントの分析および設計を担当するデプロイメント・アーキテクトやビジネス・プランナです。このガイドは、エンタープライズ・アプリケーションの設計および実装を担当するシステム・インテグレータやその他のユーザーにも役立ちます。

このドキュメントをお読みになる前に

このドキュメントでは、ソフトウェアのインストールについては説明していません。インストールの詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』を参照してください。

古いバージョンのDirectory ServerまたはDirectory Proxy Serverから移行する場合は、サーバーの移行方法について、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』を参照してください。このバージョンの新機能をよく知らない場合は、新機能の概要について、『Oracle Directory Server Enterprise Edition評価ガイド』を参照すると役立ちます。

このドキュメントの構成

第I部「デプロイメント計画の概要」では、Directory Server Enterprise Editionの概要を示し、デプロイメント計画(ソリューション・ライフ・サイクル)の手順について説明します。

第II部「技術要件」では、Directory Server Enterprise Editionデプロイメントについて定義する必要がある技術要件について説明します。

第III部「論理設計」では、一般的なDirectory Server Enterprise Editionデプロイメント・シナリオに基づくサンプル論理アーキテクチャを示します。

第IV部「高度なデプロイメント」では、特殊なデプロイメントについて説明します。

このドキュメントで使用する例

一貫性を保つため、このガイド全体で同じサンプル・データを使用します。これらの値をご使用のシステムに適した値に置き換えてください。

変数

例で使用する値

接尾辞(SUFFIX_DN)

dc=example,dc=com

インスタンスのパス(INSTANCE_PATH)

Directory Serverの場合: /local/dsInst/

Directory Proxy Serverの場合: /local/dps/

ホスト名(HOST)

host1、host2、host3

ポート(PORT)

LDAP: rootのデフォルト: 389。root以外のデフォルト: 1389

SSLのデフォルト: rootのデフォルト: 636。root以外のデフォルト: 1636

Oracle Directory Server Enterprise Editionドキュメント・セット

このドキュメント・セットでは、Oracle Directory Server Enterprise Editionを使用してディレクトリ・サービスを評価、設計、デプロイ、および管理する方法について説明します。また、Directory Server Enterprise Edition用クライアント・アプリケーションの開発方法についても説明します。Oracle Fusion Middleware Directory Server Enterprise Editionドキュメント・ライブラリは、http://docs.oracle.com/cd/E29127_01/index.htmにあります。

次の表に、Directory Server Enterprise Editionのドキュメント・セットを構成するドキュメントのリストを示します。

ドキュメント・タイトル

内容

Oracle Directory Server Enterprise Edition
リリース・ノート

既知の問題点を含め、Directory Server Enterprise Editionについての最新情報を提供しています。

Oracle Directory Server Enterprise Edition
評価ガイド

このリリースの重要な機能を紹介します。これらの機能の仕組みや提供される利点を、単独システムに実装可能なデプロイメントのコンテキストに沿って示しています。

Oracle Directory Server Enterprise Edition
デプロイメント・プランニング・ガイド

Directory Server Enterprise Editionをベースとする、可用性と拡張性に優れたディレクトリ・サービスを計画および設計する方法について説明しています。デプロイメントの計画および設計の基本的な概念および原則を提示します。ソリューションのライフ・サイクルについて検討し、Directory Server Enterprise Editionベースのソリューションを計画するために使用する概略レベルのサンプルおよび戦略を提供します。

Oracle Directory Server Enterprise Edition
インストレーション・ガイド

Directory Server Enterprise Editionソフトウェアのインストール方法について説明しています。インストール済ソフトウェアの構成方法および構成済ソフトウェアの検証方法を示します。

Oracle Directory Server Enterprise Edition
アップグレードおよび移行ガイド

バージョン11.1.1.3, 7.xおよび6のインストールをアップグレードする手順およびバージョン5.2インストールを移行する手順を示しています。

Oracle Directory Server Enterprise Edition
管理者ガイド

Directory Server Enterprise Editionをコマンドラインから管理する手順を示しています。

Directory Service Control Center(DSCC)を使用してDirectory Server Enterprise Editionを管理する際のヒントおよび手順については、DSCCのオンライン・ヘルプを参照してください。

Oracle Directory Server Enterprise Edition
リファレンス

Directory Server Enterprise Editionの技術および概念の基礎を紹介します。コンポーネント、アーキテクチャ、プロセス、および機能について説明しています。

Oracle Directory Server Enterprise Edition
マニュアル・ページ・リファレンス

Directory Server Enterprise Editionを通じて利用可能なコマンドライン・ツール、スキーマ・オブジェクトおよびその他の公開インタフェースについて説明しています。このドキュメントの個別の項を、オンライン・マニュアル・ページとしてインストールできます。

Oracle Directory Server Enterprise Edition
開発者ガイド

Directory Server Enterprise Editionの一部として提供されるツールおよびAPIを利用して、ディレクトリ・クライアント・アプリケーションを開発する方法を示しています。

Oracle Directory Server Enterprise Edition
トラブルシューティング・ガイド

様々なツールを使用して問題の範囲を特定し、データを収集し、問題部分のトラブルシューティングを行う手順について説明しています。

Identity Synchronization for Windows 6.0
リリース・ノート

Identity Synchronization for Windows 6.0 SP1のインストール、移行およびアップグレードに関する最新情報を提供します。

Identity Synchronization for Windows 6.0
デプロイメント・プランニング・ガイド

Identity Synchronization for Windowsの計画とデプロイメントに関する一般的なガイドラインやベスト・プラクティスを示しています。

Identity Synchronization for Windows 6.0
インストレーションおよび構成ガイド

Identity Synchronization for Windowsをインストールおよび構成する方法を説明しています。

Directory Server Enterprise Editionの概要は、次の図のドキュメントを記載順に確認してください。

図docmap.pngの説明

関連ドキュメント

SLAMD分散負荷生成エンジンは、ネットワークベースのアプリケーションのパフォーマンスについて負荷テストを実行し、解析するために設計されたJavaアプリケーションです。このアプリケーションは、LDAPディレクトリ・サーバーのパフォーマンスについてベンチマークを実行し、分析するためにSun Microsystems, Inc.によって開発されました。SLAMDは、OSI認定オープン・ソース・ライセンスであるSun Public Licenseに基づいて、オープン・ソース・アプリケーションとして使用できます。SLAMDの詳細は、http://www.slamd.com/を参照してください。SLAMDは、java.netプロジェクトでも提供されています。https://slamd.dev.java.net/を参照してください。

Java Naming and Directory Interface(JNDI)は、LDAPやDSML v2によるJavaアプリケーションからDirectory Serverへのアクセスに対応しています。JNDIの詳細は、http://www.oracle.com/technetwork/java/jndi/index.htmlを参照してください。JNDI Tutorialには、詳しい説明とJNDIの使用例が記載されています。このチュートリアルは、http://download.oracle.com/javase/jndi/tutorial/で参照できます。

Identity Synchronization for WindowsはMessage Queueを制限されたライセンスで使用します。Message Queueのドキュメントは、http://www.oracle.com/technetwork/indexes/documentation/index.htmlから入手できます。

Identity Synchronization for WindowsはMicrosoft Windowsのパスワード・ポリシーを扱います。

- Windows 2003のパスワード・ポリシーに関する情報は、オンラインのMicrosoftドキュメント(http://technet.microsoft.com/en-us/windowsserver/default.aspx)で入手できます。

- Microsoft証明書サービスのエンタープライズ・ルート認証局に関する情報は、オンラインのMicrosoftサポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;247078)で入手できます。

- MicrosoftシステムでのLDAP over SSLの構成に関する情報は、オンラインのMicrosoftサポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;321051)で入手できます。

再配布可能ファイル

Directory Server Enterprise Editionのファイルは、再頒布できません。

デフォルト・パスとコマンドの場所

この項では、このドキュメントで使用するデフォルトのパスについて説明し、様々なオペレーティング・システムおよびデプロイメント・タイプでのコマンドの場所を示します。

デフォルト・パス

次の表では、このドキュメントで使用するデフォルトのパスについて説明します。インストールされるファイルの詳細な説明については、『Oracle Directory Server Enterprise Editionリファレンス』の第1章「Directory Server Enterprise Editionのファイル・リファレンス」を参照してください。

プレースホルダ

説明

デフォルト値

install-path

Directory Server Enterprise Editionソフトウェアのベース・インストール・ディレクトリを表します。

unzipを使用してzipディストリビューションからインストールする場合、install-pathは、current-directory/dsee7になります。

instance-path

Directory ServerまたはDirectory Proxy Serverのインスタンスのフルパスを表します。

このドキュメントでは、Directory Serverには/local/dsInst/、Directory Proxy Serverには/local/dps/を使用します。

デフォルト・パスはありません。インスタンス・パスは、常にローカル・ファイル・システム上に存在するようにします。

Solarisシステムでは、/varディレクトリをお薦めします。

serverroot

Identity Synchronization for Windowsのインストール先の親ディレクトリを表します。

インストールごとに異なります。Directory ServerおよびDirectory Proxy Serverでは、serverrootの概念が存在しなくなったことに注意してください。

isw-hostname

Identity Synchronization for Windowsインスタンスのディレクトリを表します。

インストールごとに異なります。

/path/to/cert8.db

Identity Synchronization for Windowsにおけるクライアントの証明書データベースのデフォルト・パスおよびファイル名を表します。

current-working-dir/cert8.db

serverroot/isw-hostname/linebreaklogs/

システム・マネージャ、各コネクタ、およびセントラル・ロガーのログ・ファイルをIdentity Synchronization for Windowsがローカルに保存する場所のデフォルト・パスを表します。

インストールごとに異なります。

serverroot/isw-hostname/linebreaklogs/central/

Identity Synchronization for Windowsセントラル・ログ・ファイルのデフォルト・パスを表します。

インストールごとに異なります。

コマンドの場所

この項の次の表は、Directory Server Enterprise Editionのドキュメントで使用されるコマンドの場所を示しています。各コマンドの詳細は、関連するマニュアル・ページを参照してください。『Oracle Directory Server Enterprise Editionリファレンス』のDirectory Server Enterprise Editionのソフトウェア・レイアウトに関する説明も参照してください。

コマンド

Zipディストリビューション

certutil

install-path/bin/certutil

dpadm

install-path/bin/dpadm

dpconf

install-path/bin/dpconf

dsadm

install-path/bin/dsadm

dsccagent

install-path/bin/agent

dsccmon

install-path/bin/dsccmon

dsccreg

install-path/bin/dsccreg

dsccsetup

install-path/bin/dsccsetup

dsconf

install-path/bin/dsconf

dsmig

install-path/bin/dsmig

dsutil

install-path/bin/dsutil

entrycmp

install-path/bin/entrycmp

fildif

install-path/bin/fildif

idsktune

解凍したzipディストリビューションのroot

insync

install-path/bin/insync

ldapmodify

install-path/dsrk/bin/ldapmodify

ldapsearch

install-path/dsrk/bin/ldapsearch

repldisc

install-path/bin/repldisc

表記規則

次の表に、このドキュメントで使用する表記規則を示します。

書体

意味

例

AaBbCc123

コマンド名、ファイル名、ディレクトリ名、画面上のコンピュータ出力を示します。

.loginファイルを編集します。

ls aを使用してすべてのファイルをリストします。

machine_name% you have mail.

AaBbCc123

ユーザーが入力する文字を、画面上のコンピュータ出力と区別して示します。

machine_name% su

Password:

aabbcc123

プレースホルダ: 実際の名前または値で置き換えます。

ファイルを削除するコマンドはrm filenameです。

AaBbCc123

書名、新規用語および強調する用語を示します。

『ユーザーズ・ガイド』の第6章を参照してください。

キャッシュとは、ローカルに格納されるコピーです。

このファイルは保存しないでください。

注意: 強調する一部の項目は、オンラインで太字で表示されます。

コマンド例でのシェル・プロンプト

次の表に、Oracle Solaris OSに含まれるシェルのデフォルトのUNIXシステム・プロンプトとスーパーユーザー・プロンプトを示します。コマンド例に表示されるデフォルトのシステム・プロンプトは、Oracle Solarisのリリースによって異なることに注意してください。

シェル

プロンプト

Bashシェル、KornシェルおよびBourneシェル

$

Bashシェル、KornシェルおよびBourneシェル(スーパーユーザーの場合)

#

Cシェル

machine_name%

Cシェル(スーパーユーザーの場合)

machine_name#

記号の表記規則

次の表では、このドキュメントで使用される記号について説明します。

記号

説明

例

意味

[ ]

省略可能な引数やコマンドオプションが含まれます。

ls [-l]

-lオプションは省略可能です。

{ | }

必須のコマンドオプションの選択肢を囲みます。

-d {y|n}

-dオプションでは、yかnのどちらかの引数を使用する必要があります。

${ }

編集参照を示します。

${com.sun.javaRoot}

com.sun.javaRoot変数の値を参照します。

-

同時に押すキーを連結します。

Control-A

[Ctrl]キーと[A]キーを同時に押します。

+

連続して押すキーを連結します。

Ctrl+A+N

[Ctrl]キーを押し、放してから以後のキーを続けて押します。

>

グラフィカル・ユーザー・インタフェースで選択するメニュー項目を示します。

「ファイル」→「新規」→「テンプレート」

「ファイル」メニューから「新規」を選択します。「新規」サブメニューから「テンプレート」を選択します。

ドキュメント、サポートおよびトレーニング

次のWebサイトでは、追加の情報が提供されています。

- ドキュメント(http://www.oracle.com/technetwork/indexes/documentation/index.html)

- サポート(http://www.oracle.com/us/support/systems/index.html)

- トレーニング(http://education.oracle.com)

Oracleソフトウェア・リソース

Oracle Technology Network (http://www.oracle.com/technetwork/index.html)には、Oracleソフトウェアに関連する様々なリソースがあります。

- ODSEEディスカッション・フォーラム(http://forums.oracle.com/forums/forum.jspa?forumID=877)およびDirectory Servicesブログ(http://blogs.oracle.com/directoryservices/)で、技術的な問題や解決策について検討してください。

- 最新のお知らせは、Directory Servicesブログ(http://blogs.oracle.com/directoryservices/)で確認してください。

- ODSEE 11gサンプル・ファイル(http://www.oracle.com/technetwork/middleware/id-mgmt/learnmore/odsee11113-examples-350399.zip)をダウンロードしてください。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

第I部

デプロイメント計画の概要

ここでは、Directory Server Enterprise Editionの概要を示し、デプロイメント計画(ソリューション・ライフ・サイクル)のステップについて説明します。次の章で構成されています。

- 第1章「Directory Server Enterprise Editionのデプロイメント計画の概要」では、デプロイメント計画プロセスについて説明します。

- 第2章「Directory Server Enterprise Editionのビジネス分析」では、ビジネス要件について説明します。

デプロイメント計画プロセスの詳細は、第1章「Directory Server Enterprise Editionのデプロイメント計画の概要」を参照してください。

1 Directory Server Enterprise Editionのデプロイメント計画の概要

この章では、Oracle Directory Server Enterprise Editionおよびデプロイメント計画プロセスの概要を示します。

この章の内容は、次のとおりです。

- デプロイメント計画について

- ソリューション・ライフ・サイクル

1.1 デプロイメント計画について

デプロイメント計画は、Directory Server Enterprise Editionソリューションを適切に実装するための重要なステップとなります。企業は、それぞれの独自の目標、要件および優先順位を検討します。計画を成功させるには、まず企業の目標を分析し、これらの目標を満たすためのビジネス要件を特定します。次に、ビジネス要件を技術要件に変換する必要があります。技術要件は、企業の目標を満たすシステムを設計および実装する基礎として使用できます。

デプロイメント計画を成功させるには、慎重に準備、分析および設計する必要があります。計画プロセス中のエラーや誤りによって、システムに様々な問題が発生する場合があります。適切に計画されていないシステムでは、重大な問題が発生する可能性があります。たとえば、システムのパフォーマンスが低下する、保守が困難になる、運用コストが高くなる、拡張できなくなるなどの可能性があります。

デプロイメント計画の原則については、第1章「Directory Server Enterprise Editionのデプロイメント計画の概要」で詳細に説明します。このガイドで示すソリューション・ライフ・サイクルでは、明確に定義されたステップに沿ってデプロイメント計画に取り組みます。

1.1.1 デプロイメントのDirectory Server Enterprise Editionコンポーネント

デプロイするDirectory Server Enterprise Editionコンポーネントの組合せは、組織の要件によって異なります。次の図は、前に説明したコンポーネントを使用する一般的なデプロイメント・シナリオを示します。

図1-1 Directory Server Enterprise Editionコンポーネント

「図1-1 Directory Server Enterprise Editionコンポーネント」の説明

1.2 ソリューション・ライフ・サイクル

次の図に示すソリューション・ライフ・サイクルは、Oracle Fusion Middlewareに基づくエンタープライズ・ソフトウェア・ソリューションの計画、設計および実装におけるステップを示しています。ライフ・サイクルは、デプロイメント・プロジェクトを順調に進めるために役立つツールです。ソリューション・ライフ・サイクルについては、第1章「Directory Server Enterprise Editionのデプロイメント計画の概要」で詳細に説明します。

図1-2 ソリューション・ライフ・サイクル

「図1-2 ソリューション・ライフ・サイクル」の説明

2 Directory Server Enterprise Editionのビジネス分析

ソリューションのライフ・サイクルのビジネス分析フェーズでは、ビジネス上の問題を分析することによってビジネス目標を定義します。次に、これらの目標を満たすためのビジネス要件とビジネス上の制約を特定します。

この章は次の項で構成されています。

- ビジネス分析について

- Directory Server Enterprise Editionのビジネス要件の定義

2.1 ビジネス分析について

ビジネス分析では、まずビジネス目標を記述します。次に、解決する必要があるビジネス上の問題を分析し、ビジネス目標を達成するために満たす必要があるビジネス要件を特定します。目標の達成能力を制限するビジネス上の制約を考慮します。ビジネス要件と制約の分析の結果は、一連のビジネス要件のドキュメントになります。

完成した一連のビジネス要件のドキュメントは、技術要件フェーズで、技術要件を導出するための基礎として使用します。ソリューションのライフ・サイクル全体で、ビジネス分析フェーズで実行した分析に従って計画およびソリューションの成果を評価します。

2.2 Directory Server Enterprise Editionのビジネス要件の定義

ビジネス要件を簡単に特定する方法はありません。ビジネス要件は、アイデンティティ管理ソリューションが要求される利害関係者との連携、ビジネス領域に関する知識、および適用される創造的思考に基づいて特定されます。第2章「Directory Server Enterprise Editionのビジネス分析」では、ビジネス・分析プロセスについて詳細に説明します。ビジネス要件および制約を定義するときに考慮する要素も含まれています。この項では、堅牢なディレクトリ・サービスのニーズが発生するビジネス要件について概説します。

企業では、次の状況において、堅牢なディレクトリ・サービスが必要となります。

- 常に拡大および変化するユーザー基盤に対して、重要なビジネス情報およびアプリケーションを利用できるようにする必要がある場合。

- これらのユーザーには、内部の従業員だけでなく、顧客、ベンダー、その他のビジネス・パートナなどの外部ユーザーも含まれる場合。

ディレクトリ・サービスでは、効果的なアイデンティティ管理インフラストラクチャのための可用性、スケーラビリティ、管理性、統合性およびセキュリティの高い基盤を提供することによって、これらのニーズに対応します。このサービスによって、ユーザーのアイデンティティ・データを管理し、Webサービス・アーキテクチャのデータをサポートするための集中管理データ・ストアを提供する一連の機能が提供されます。

効果的なアイデンティティ管理インフラストラクチャを提供することで、ディレクトリ・サービスは、ユーザーおよびユーザーによるジョブの実行に役立つアプリケーションへのサービス提供に関連する主な企業の要件に対処します。

これらの要件には次のものがあります。

- 大規模で常に変化するユーザー・グループへのアクセスの解放

- 情報を適切に使用および共有し、機密情報を保護するためのセキュリティの向上

- 常に信頼できるアクセスおよび高いサービス品質をユーザーやアプリケーションに対して提供すること

- ビジネス・ニーズの変化やユーザー要件の拡大に関係なく、情報およびサービスを効率的にユーザーに提供すること

可用性、信頼性およびセキュリティの高い、高パフォーマンスのディレクトリ・サービスは、主なビジネス要因(セキュリティ、サービス品質およびコスト効率)に対応します。

第II部

技術要件

技術要件分析は、ソリューション・ライフ・サイクルのビジネス分析フェーズで作成されたビジネス要件のドキュメントから始まります。ビジネス分析を使用して、使用状況分析を実行します。この分析により、予期される負荷条件を特定したり、ユーザーとシステムの一般的なやり取りをモデル化するユースケースを作成できます。分析は、一連のサービス品質要件の作成にも役立ちます。これらの要件では、デプロイされたソリューションをレスポンス時間、可用性、セキュリティなどの領域で実行する方法を定義します。

ここでは、Directory Server Enterprise Editionデプロイメントに対して定義する必要がある技術要件について説明します。これは次の各章で構成されています。

- 第3章「Directory Server Enterprise Editionの使用状況分析」では、使用状況分析要件について説明します。

- 第4章「データ特性の定義」では、データ要件の定義方法について説明します。

- 第5章「サービス・レベル合意の定義」では、サービス品質要件について説明します。

- 第6章「システムの特性のチューニングおよびハードウェアのサイズ設定」では、Directory Server Enterprise Editionのシステム要件について説明します。

- 第7章「セキュリティ要件の特定」では、セキュリティ要件について説明します。

- 第8章「管理および監視の要件の特定」では、管理に関して設計時に決定する必要がある事項について説明します。

3 Directory Server Enterprise Editionの使用状況分析

使用状況分析では、システムのユーザーを識別し、それらのユーザーの使用パターンを特定します。このようにして、使用状況分析を使用することで、ディレクトリ・サービスの予期される負荷条件を特定できます。

3.1 使用状況分析の要素

Oracle Directory Server Enterprise Editionをアイデンティティ管理ソリューションとして提供する理由は、サーバーをどのようにデプロイするかに直接影響を及ぼします。

使用状況分析では、可能なかぎりユーザーにインタビューします。使用パターンに関する既存のデータを調査し、前のシステムの構築者や管理者にインタビューします。使用状況分析により、サービス要件を特定できるデータが提供されます(第5章「サービス・レベル合意の定義」を参照)。

使用状況分析では、次のような情報を得ることができます。

- クライアント・アプリケーションの数とタイプ。デプロイメントでサポートする必要があるクライアント・アプリケーションの数を特定し、必要に応じてそれらのアプリケーションを分類します。

- 管理ユーザー。ディレクトリにアクセスしてデプロイメントを監視、更新およびサポートするユーザーを特定します。技術要件に影響する可能性がある特定の管理使用パターン(ファイアウォールの外側からのデプロイメント管理など)を特定します。

- 使用パターン。様々なタイプのアプリケーションがどのようにシステムにアクセスするかを特定し、予想される使用率の目標を設定します。
次のような質問に回答します。

- 使用率のスパイクが発生する時間はありますか。

- 通常の業務時間はいつですか。

- クライアント・アプリケーションはグローバルに分散されますか。

- アプリケーション接続の予期される持続時間はどのくらいですか。

- クライアント・アプリケーションの増加。クライアント・アプリケーションの数が固定されているか、増加が予想されるかを判断します。アプリケーションが追加されることが予想される場合は、どの程度の増加が見込まれるかを予測します。

- アプリケーション・トランザクション。サポートする必要のあるトランザクションのタイプを特定します。
これらのトランザクションは、次のようなことに基づき、ユースケースに分類できます。

- アプリケーションでどのようなタスクが実行されるか。

- アプリケーションがディレクトリにバインドした後、バインド状態を維持するか、またはいくつかのタスクを実行してからバインドを解除するか。

- 研究および統計データ。既存の研究およびその他のソースを使用して、アプリケーションの動作パターンを特定します。多くの場合、企業または業界団体は調査研究を行い、その中からユーザーやクライアント・アプリケーションに関する有用な情報を抽出できます。既存のアプリケーションのログ・ファイルには、システムの見積りに役立つ統計データが含まれている場合があります。

使用状況分析の詳細は、第3章「Directory Server Enterprise Editionの使用状況分析」を参照してください。

4 データ特性の定義

ディレクトリに格納するデータのタイプによって、ディレクトリの構造、データにアクセスできるユーザーおよびアクセス権の付与方法が決定されます。データのタイプには、特にユーザー名、電子メール・アドレス、電話番号およびユーザーが所属するグループに関する情報などがあります。

この章では、データを検索、分類、構造化および整理する方法について説明します。また、Directory Serverのスキーマにデータをマップする方法についても説明します。この章の内容は、次のとおりです。

- データソースと所有者の決定

- 異種データソースからのデータの特定

- DITの設計

- ディレクトリ・スキーマの設計

- その他のディレクトリ・データ・リソース

4.1 データソースと所有者の決定

既存のデータを分類する最初の手順では、そのデータの発生源と所有者を特定します。

4.1.1 データソースの特定

ディレクトリに格納するデータを特定するには、既存のデータソースを探して分析します。

- 情報を提供する組織を特定します。
企業にとって重要な情報を管理しているすべての組織を特定します。通常、これらの組織には、情報サービス部門、人事管理部門、給与部門、会計部門などがあります。

- 情報源となるツールおよびプロセスを特定します。
一般的な情報源には、次のものがあります。

- Windows、Novell Netware、UNIX NISなどのネットワーク対応オペレーティング・システム

- 電子メール・システム

- セキュリティ・システム

- PBXまたは電話交換システム

- 人事管理アプリケーション

- それぞれのデータを集中化することがデータの管理に及ぼす影響を判定します。
データの集中管理には、新しいツールと新しいプロセスが必要となる場合があります。集中化によって、組織ごとにスタッフを増減することが必要となる場合は、問題が発生することがあります。

4.1.2 データ所有者の決定

データ所有者とは、データを最新の状態に維持することに責任を負う個人または組織のことです。データ設計フェーズで、ディレクトリにデータを書き込みできるユーザーを決定します。データの所有者を決定する一般的な方針は、次のとおりです。

- 数名のディレクトリ・コンテンツ・マネージャのグループを除くすべてのユーザーに対して、ディレクトリへの読取り専用アクセスを許可します。

- 個々のユーザーが、情報の戦略的なサブセットを管理できるようにします。
このような情報のサブセットには、自分のパスワード、ユーザー自身に関する具体的な情報、組織内での自分のロールなどがあります。

- 連絡先情報や役職など、一部の情報の戦略的なサブセットに対しては、その個人のマネージャに書込みを許可します。

- 組織の管理者が、その組織に関するエントリを作成および管理できるようにします。
実質的に、組織の管理者がディレクトリ・コンテンツ・マネージャになります。

- ユーザーのグループに読取りまたは書込みのアクセス権を付与するロールを作成します。
たとえば、人事管理、財務、会計などのロールを作成します。これらのロールごとに、そのグループが必要とするデータへの読取りアクセス権、書込みアクセス権またはその両方を許可します。このようなデータには、給与情報、政府指定の識別番号、自宅の電話番号と住所などがあります。

ロールおよびエントリのグループ化の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第9章「Directory Serverのグループ、ロールおよびCoS」およびOracle Directory Server Enterprise Editionリファレンスの第11章「Directory Serverのグループとロール」を参照してください。

データへの書込みを許可するユーザーを決定するとき、複数のユーザーに、同じデータへの書込みアクセス権が必要になることがあります。たとえば、情報システム・グループまたはディレクトリ管理グループには、従業員のパスワードへの書込みアクセス権を付与する場合があります。また、すべての従業員にも、自分自身のパスワードへの書込みアクセス権を付与する場合があります。一般的には複数のユーザーに同じ情報への書込みアクセス権を付与する必要がありますが、このようなグループは少人数に保ち、容易に特定できるようにします。グループを少人数にすることは、データの整合性確保に役立ちます。

ディレクトリのアクセス制御設定の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」およびOracle Directory Server Enterprise EditionリファレンスのDirectory Serverがアクセス制御を提供する仕組みに関する説明を参照してください。

4.1.3 ユーザー・データと構成データの区別

Directory Serverやその他のOracle Fusion Middlewareサーバーの構成に使用されるデータと、ディレクトリに格納される実際のユーザー・データを区別するには、次のことを実行します。

- ユーザー・データおよび構成データに対して、異なるバックアップ計画を用意します。

- ユーザー・データおよび構成データに対して、異なる高可用性標準を用意します。

- 構成サーバーを迅速に停止、リストアおよび起動します。

- 他のDirectory Serverインスタンスのメンテナンス実行中は、構成サーバーを稼働したままにします。

4.2 異種データソースからのデータの特定

データソースを特定する場合は、従来のデータソースを含め、他のデータソースからのデータを必ず対象としてください。このデータは、ディレクトリに格納されていない場合があります。ただし、Directory Serverが、そのデータに関して、なんらかの情報や、制御できることが必要となる場合があります。

Directory Proxy Serverには、複数のデータ・リポジトリからリアルタイムで情報を集計する仮想ディレクトリ機能があります。このようなリポジトリには、LDAPディレクトリ、JDBC仕様に準拠するデータおよびLDIFフラット・ファイルなどがあります。

仮想ディレクトリは、様々なデータソースからの属性を処理する複合フィルタをサポートしています。また、様々なデータソースからの属性を結合する変更もサポートします。

データ分析フェーズにおいて、複数のアプリケーションが、同じデータを、異なる形式で必要とすることが判明する場合があります。このようなデータについては、複製するのではなく、アプリケーションで、それぞれの要件に合わせてデータを変換することが推奨されます。

4.3 DITの設計

DITの設計では、データを格納する接尾辞の選択、データ・エントリ間の階層関係の決定およびDIT階層内のエントリのネーミングを行います。DITは、ディレクトリ・データへのアクセスをどのように分散、レプリケート、制御するかなどの、設計上のその他の決定事項と緊密に相互作用します。

以降の項では、DITの設計プロセスについて詳しく説明します。

4.3.1 接尾辞の選択

接尾辞は、DITのルートにあるエントリの名前です。共通の実ルートを持たないDITが2つ以上ある場合は、複数の接尾辞を使用できます。デフォルトのDirectory Serverのインストールには、複数の接尾辞が含まれています。一方の接尾辞はユーザー・データの格納に使用されます。もう一方の接尾辞は、構成情報やディレクトリ・スキーマなど、内部的なディレクトリ操作に必要なデータに使用されます。

すべてのディレクトリ・エントリは、共通のベース・エントリ(接尾辞)の下に配置する必要があります。各接尾辞名に必要とされることは、次のとおりです。

- グローバルに一意であること

- 静的であり、名前がほとんど変更されないこと

- 簡潔であり、接尾辞の下のエントリが、オンラインで読みやすいこと

- ユーザーが入力しやすく、記憶しやすいこと

一般的には、企業のドメイン名を識別名(DN)にマップすることが、ベスト・プラクティスと考えられています。たとえば、example.comというドメイン名を持つ企業の場合は、dc=example,dc=comというDNを使用します。

4.3.2 DIT構造の作成とエントリのネーミング

DITの構造は、フラット型または階層型から選択できます。フラット・ツリーの方が管理は容易ですが、データのパーティション化、レプリケーション管理およびアクセス制御のために、ある程度の階層が必要となる場合もあります。

4.3.2.1 ブランチ・ポイントとネーミングに関する考慮事項

ブランチ・ポイントとは、DIT内に新しいサブ区分を定義するポイントのことです。ブランチ・ポイントを決定する場合は、問題のある名前変更が発生する可能性がないようにします。名前変更の可能性は、名前の中の、変更される可能性のあるコンポーネントの数に比例します。DITの階層が深くなるほど、名前の中により多くのコンポーネントが含まれ、名前が変更される可能性が高まります。

ブランチ・ポイントを定義および命名する場合は、次のガイドラインに従います。

- 企業内で最大の組織サブ区分のみを表すように、ツリーにブランチを作成します。
ブランチ・ポイントは、部門(企業情報サービス、カスタマ・サポート、販売、プロフェッショナル・サービスなど)に限定します。その部門が固定されていることを確認します。企業で組織変更が頻繁に行われる場合は、この種類のブランチは作成しないでください。

- 実際の組織名ではなく、機能名または一般名を使用します。
名前は変更されるため、企業が部門の名前を変更するたびにDITの変更が必要になることは適切ではありません。そのかわり、組織の機能を表す汎用的な名前を使用します。たとえば、Widget研究開発ではなく、エンジニアリングを使用します。

- 類似した機能を持つ複数の組織がある場合は、部門の構成に基づいてブランチを作成するのではなく、その機能を表す単一のブランチ・ポイントを作成します。
たとえば、特定の製品ラインを担当する複数のマーケティング部門がある場合でも、作成するマーケティング・サブツリーは1つのみとします。そのツリーに、すべてのマーケティング・エントリが所属します。

- 次の表に示す、従来のブランチ・ポイント属性のみを使用するようにします。
従来の属性を使用すると、サード・パーティのLDAPクライアント・アプリケーションとの互換性が保たれる可能性が高くなります。さらに、従来の属性は、デフォルトのディレクトリ・スキーマに対応しているため、ブランチの識別名(DN)のエントリ構築が容易になります。

- ディレクトリに格納されるデータのタイプに応じてブランチを作成します。
たとえば、ユーザー、グループ、サービスおよびデバイスについて、個別のブランチを作成します。

表4-1 従来のDNブランチ・ポイントの属性

属性名

定義

c

国名。

o

組織名。この属性は、通常、大規模な部門のブランチを表すために使用します。このようなブランチの例には、企業の部門、教育機関の学部、子会社、企業内のその他の主要部門などがあります。また、ドメイン名を表す場合にも、この属性を使用する必要があります。

ou

組織単位。この属性は、通常、企業における、組織よりも小さい部門のブランチを表すために使用します。一般的に、組織単位はすぐ上の組織に属しています。

st

都道府県名。

l

地域(都市、地方、オフィス、施設名など)。

dc

ドメイン・コンポーネント。

ブランチ・ポイントの属性を選択する場合は、一貫性を保つようにしてください。DIT全体でDNの形式が統一されていないと、一部のLDAPクライアント・アプリケーションで問題が発生する可能性があります。DITのある部分でl (localityName)がo (organizationName)の下位に属する場合は、ディレクトリのその他のすべての部分でもlがoの下位となるようにしてください。

4.3.2.2 レプリケーションに関する考慮事項

DITを設計する場合は、どのエントリが他のサーバーにレプリケートされるかを検討します。エントリの特定グループを同じ一連のサーバーにレプリケートする場合は、それらのエントリが特定のサブツリーの下に配置されている必要があります。レプリケートするエントリのセットを記述するには、サブツリーの最上部でDNを指定します。エントリをレプリケートする方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。

4.3.2.3 アクセス制御に関する考慮事項

DIT階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様、類似のエントリをグループ化して、そのエントリを単一のブランチから管理すると、より簡単になります。

階層DITでは、分散管理を実現することもできます。たとえば、DITを使用して、マーケティング部門の管理者にはマーケティングに関するエントリへのアクセス権を付与し、販売部門の管理者には販売に関するエントリへのアクセス権を付与できます。

DITではなく、ディレクトリの内容に基づいて、アクセス制御を設定することもできます。ACIでフィルタされたターゲット・メカニズムを使用して、単一のアクセス制御ルールを定義します。このルールでは、1つのディレクトリ・エントリが、特定の属性値を含むすべてのエントリにアクセスできることを規定します。たとえば、ou=Salesという属性を含むすべてのエントリへのアクセス権を、販売部門の管理者に付与するACIフィルタを設定できます。

ただし、ACIフィルタは管理が難しい場合があります。対象のディレクトリに最適なアクセス制御方法が、DIT階層で組織に対応したブランチの作成、ACIフィルタ、その2つの組合せなどのうち、どれであるかを判断する必要があります。

4.4 ディレクトリ・スキーマの設計

ディレクトリ・スキーマは、ディレクトリに格納できるデータのタイプを記述します。スキーマ設計により、各データ要素がLDAP属性にマップされます。関連する要素は、LDAPオブジェクト・クラスにまとめられます。適切に設計されたスキーマは、データ値のサイズ、範囲および形式を制限することによって、データの整合性維持に役立ちます。ディレクトリに格納するエントリのタイプと、各エントリで使用できる属性を決定します。

Directory Serverに付属の事前定義済スキーマには、Internet Engineering Task Force (IETF)標準のLDAPスキーマが含まれています。このスキーマには、サーバーの機能をサポートするための、アプリケーション固有の追加スキーマが含まれます。また、Directory Server固有のスキーマ拡張も含まれています。このスキーマはほとんどのディレクトリ要件を満たしますが、対象のディレクトリに固有の新しいオブジェクト・クラスと属性で、スキーマを拡張することが必要な場合もあります。

4.4.1 スキーマ設計プロセス

スキーマ設計では、次のことを実行する必要があります。

- デフォルト・スキーマへのデータのマッピング
既存のデータをデフォルト・スキーマにマップするには、各データ要素で記述されるオブジェクトの型を識別してから、類似のオブジェクト・クラスをデフォルト・スキーマから選択します。グループ、ユーザー、組織など、共通のオブジェクト・クラスを使用します。データ要素に最も一致するオブジェクト・クラスから、類似の属性を選択します。

- 一致しないデータを特定します。

- デフォルト・スキーマを拡張して、残りのニーズを満たす新しい要素を定義します。
デフォルトのディレクトリ・スキーマで定義されているオブジェクト・クラスおよび属性に一致しないデータ要素がある場合は、スキーマをカスタマイズします。また、スキーマを拡張して、既存のスキーマに制約を追加することもできます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のカスタム・スキーマに関する説明を参照してください。

- スキーマのメンテナンスを計画します。

可能な場合は、デフォルトのDirectory Serverスキーマで定義されている、既存のスキーマ要素を使用します。標準のスキーマ要素を使用すると、ディレクトリ対応アプリケーションとの互換性を確保しやすくなります。このスキーマはLDAP標準に基づいているため、多数のディレクトリ・ユーザーによるレビューおよび合意を経ています。

4.4.2 データの一貫性の維持

データの一貫性を保つことで、LDAPクライアント・アプリケーションがディレクトリ・エントリを検索しやすくなります。ディレクトリに格納される情報のタイプごとに、その情報をサポートするために必要なオブジェクト・クラスおよび属性を選択します。オブジェクト・クラスと属性は、常に同じものを使用してください。スキーマ・オブジェクトの使用に一貫性がないと、情報を見つけにくくなります。

スキーマの一貫性を維持するには、次の手順を実行します。

- スキーマ・チェックを使用して、属性とオブジェクト・クラスがスキーマ・ルールに従っていることを確認します。
スキーマ・チェックの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第11章「Directory Serverのスキーマ」を参照してください。

- 一貫性のあるデータ形式を選択して適用します。
LDAPスキーマを使用すると、任意の属性値に必要なデータを格納できます。ただし、使用するLDAPクライアント・アプリケーションおよびディレクトリ・ユーザーに適切な形式を選択して、DIT内で一貫性を保ってデータを格納する必要があります。LDAPプロトコルおよびDirectory Serverを使用する場合は、RFC 4517で規定されたデータ形式を使用して、データを表現する必要があります。

4.5 その他のディレクトリ・データ・リソース

標準LDAPスキーマおよびDIT設計の詳細は、次のサイトを参照してください。

- RFC 4510: 「Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map」(http://www.ietf.org/rfc/rfc4510.txt)

- RFC 4511: 「Lightweight Directory Access Protocol (LDAP): The Protocol」(http://www.ietf.org/rfc/rfc4511.txt)

- RFC 4512: 「Lightweight Directory Access Protocol (LDAP): Directory Information Models」(http://www.ietf.org/rfc/rfc4512.txt)

- RFC 4513: 「Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms」(http://www.ietf.org/rfc/rfc4513.txt)

- RFC 4514: 「Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names」(http://www.ietf.org/rfc/rfc4514.txt)

- RFC 4515: 「Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters」(http://www.ietf.org/rfc/rfc4515.txt)

- RFC 4516: 「Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator」(http://www.ietf.org/rfc/rfc4516.txt)

- RFC 4517: 「Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules」(http://www.ietf.org/rfc/rfc4517.txt)

- RFC 4518: 「Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation」(http://www.ietf.org/rfc/rfc4518.txt)

- RFC 4519: 「Lightweight Directory Access Protocol (LDAP): Schema for User Applications」(http://www.ietf.org/rfc/rfc4519.txt)

- 『Understanding and Deploying LDAP Directory Services』T.Howes、M. Smith、G. Good. Macmillan Technical Publishing、1999

Directory Server Enterprise Editionでサポートされている、すべてのRFCおよび標準規格の一覧は、『Oracle Directory Server Enterprise Edition評価ガイド』の付録A「Directory Server Enterprise Editionでサポートされている標準規格とRFC」を参照してください。

5 サービス・レベル合意の定義

サービス・レベル合意は、特定の条件下におけるシステムの実行方法を決定する技術仕様です。この章では、Directory Server Enterprise Editionに固有のサービス要件について説明します。デプロイメントがこれらの要件を満たすようにするために、計画フェーズで確認する必要がある項目も含まれています。

この章の内容は、次のとおりです。

- システム品質の特定

- パフォーマンス要件の定義

- 可用性要件の定義

- スケーラビリティ要件の定義

- セキュリティ要件の定義

- 潜在処理能力要件の定義

- 運用性要件の定義

5.1 システム品質の特定

システム品質を特定するには、ディレクトリ・サービスで提供する必要がある最小要件を指定します。通常、次のシステム品質がサービス品質要件の基礎となります。

- パフォーマンス。ユーザー負荷条件に関するレスポンス時間とスループットの測定値。

- 可用性。エンド・ユーザーがシステムのリソースやサービスにアクセスできる頻度(システムの稼働時間と表現されることが多い)。

- スケーラビリティ。デプロイされたシステムに容量やユーザーを徐々に追加できる能力。通常、スケーラビリティには、デプロイメント・アーキテクチャを変更しないでシステムにリソースを追加できることが含まれます。

- セキュリティ。システムとそのユーザーの整合性を示す要素の複雑な組合せ。セキュリティには、ユーザーの認証と認可、データのセキュリティおよびデプロイされたシステムへのセキュア・アクセスが含まれます。

- 潜在処理能力。通常と異なるピーク時の負荷をリソースを追加しないで処理できるシステムの能力。潜在処理能力は、可用性、パフォーマンスおよびスケーラビリティにおける要素です。

- 運用性。システムの監視、発生した問題の解決、ハードウェア・コンポーネントやソフトウェア・コンポーネントのアップグレードなど、デプロイされたシステムを簡単に保守できること。

5.2 パフォーマンス要件の定義

パフォーマンス要件は、ディレクトリ使用状況の一般的なモデルに基づく必要があります。すべてのディレクトリ・デプロイメントにおいて、Directory Serverで1つ以上のクライアント・アプリケーションがサポートされており、これらのアプリケーションの要件を評価する必要があります。ディレクトリに格納される情報の量およびその情報へのアクセス頻度を見積もるには、これらのアプリケーションおよびそのDirectory Serverの使用方法を特定する必要があります。

5.2.1 クライアント・アプリケーションの特定

ディレクトリにアクセスするアプリケーションと、これらのアプリケーションのデータのニーズは、パフォーマンス要件に大きく影響します。クライアント・アプリケーションを特定するときは、次の点を考慮してください。

- Directory Serverにアクセスするクライアント・アプリケーションのタイプ

- これらの各アプリケーションにアクセスするユーザーの数

- これらのアプリケーションで実行する操作の種類

- これらの操作の使用パターン

ディレクトリを使用する可能性がある一般的なアプリケーションは次のとおりです。

- 電話帳などのブラウザ・アプリケーション。通常、このタイプのアプリケーションは、電子メール・アドレス、電話番号、従業員名などの情報にアクセスします。

- メッセージ・アプリケーション(特に電子メール・サーバー)。どの電子メール・サーバーにも、電子メール・アドレス、ユーザー名およびルーティング情報が必要です。ユーザーのメールボックスが格納されるディスク上の場所、休暇通知情報、プロトコル情報など、さらに詳細な情報を必要とするサーバーもあります。

- ディレクトリ対応の人事管理アプリケーション。これらのアプリケーションには、政府指定の識別番号、自宅の住所と電話番号、給与詳細などのより個人的な情報が必要です。

- セキュリティ、Webポータルまたはパーソナライズ・アプリケーション。このタイプのアプリケーションは、プロファイル情報にアクセスします。

各アプリケーションで使用される情報を特定すると、一部のタイプのデータが複数のアプリケーションで使用されていることがわかる場合があります。計画段階でこのようなことを行うと、データの重複を回避するのに役立ちます。

5.2.2 ディレクトリ・エントリの数とサイズの特定

ディレクトリに格納されるエントリの数とサイズは、第4章「データ特性の定義」で説明されているデータ要件によって大きく異なります。

エントリの数とサイズを計算するときは、次の点を考慮してください。

- デプロイメントにおいて、一括インポートによる初期化が繰り返し必要になるかどうか

- 必要な場合、インポートを実行する頻度

- 一度にインポートするエントリの数

- インポートするエントリのタイプ

- サーバーの実行中に初期化をオンラインで実行する必要があるかどうか

5.2.3 読取り数の特定

読取りトラフィックを見積もるときは、次の点を考慮してください。

- 1秒当たりの予想される検索数

- 予想される検索のタイプ
たとえば、一意のID検索、ワイルドカード検索、完全一致検索などがあります。

- ピーク時の検索速度の見積り

- 平均検索速度の見積り

- 予想される索引を使用しない検索の数
索引を使用しない検索とは、索引ファイルではなく、データベースを直接検索することを意味します。索引を使用しない検索が行われるのは、検索に使用される索引ファイル内ですべてのIDのしきい値に到達したとき、索引ファイルが存在しないとき、または検索に必要な方法で索引ファイルが構成されていないときです。

通常、索引を使用しない検索は、索引を使用する検索よりも時間がかかります。

- 検索が特定のデータ・センターまたは地理的領域に集中するかどうか
あるデータ・センターにおける検索トラフィックが他のデータ・センターよりも比例的に多い場合は、負荷のバランスを取るために、そのデータ・センターに追加のレプリケートされたサーバーを配置する価値があります。

- 検索が特定の時刻に集中するかどうか

- 予想されるファイアウォールの内側からの検索数

- 予想されるファイアウォールの外側からの検索数

読取りパフォーマンスが企業にとって重要である場合は、第10章「スケーラビリティを持つデプロイメントの設計」で、読取り用に拡張されたディレクトリ・サービスのデプロイに関する推奨事項を参照してください。

5.2.4 書込み数の特定

書込みトラフィックを見積もるときは、次の点を考慮してください。

- 1秒当たりの予想される更新数

- 予想される更新のタイプ

- ピーク時の更新速度の見積り

- 平均更新速度の見積り

- 更新が特定のデータ・センターまたは地理的領域に集中するかどうか
あるデータ・センターにおける更新トラフィックが他のデータ・センターよりも比例的に多い場合は、更新負荷を分散するために、そのデータ・センターに追加の書込み可能サーバーを配置する価値があります。

- 更新が特定の時刻に集中するかどうか

書込みパフォーマンスが企業にとって重要である場合は、第10章「スケーラビリティを持つデプロイメントの設計」で、書込み用に拡張されたディレクトリ・サービスのデプロイに関する推奨事項を参照してください。

5.2.5 許容できるレスポンス時間の見積り

クライアント・アプリケーションごとに、許容できる最大レスポンス時間を決定します。許容できるレスポンス時間は、地理的な場所および操作の種類によって異なる場合があります。

5.2.6 許容できるレプリケーション待機時間の見積り

マスター・レプリカとコンシューマ・レプリカ間の必要な同期レベルを見積もります。Directory Serverのレプリケーション・モデルは一貫性に関して厳密ではなく、トポロジ内の他のレプリカと通信しなくてもマスターで更新が受け入れられます。特定の時点で各レプリカの内容が異なる可能性があります。時間の経過とともに、レプリカは収束され、各レプリカのデータのコピーが同じになります。パフォーマンス計画の一環として、レプリカが収束する必要がある最大許容時間を決定します。

Directory Server 6.xから、新しい優先順位付きレプリケーション機能が追加されました。この機能を使用すると、特定の属性に対する変更を可能なかぎり早くレプリケートするように指定できます。優先順位付きレプリケーションは、許容できるレプリケーション待機時間に関する決定に影響する場合があります。詳細は、「優先順位付きレプリケーション」を参照してください。

5.3 可用性要件の定義

可用性とは、ディレクトリ・サービスについて合意された最小限の稼働時間およびパフォーマンス・レベルを意味します。このコンテキストでは、障害とは、ディレクトリ・サービスがこの最低レベルのサービスを提供することを妨げるものとして定義されます。

可用性要件を評価するときは、次の点を考慮してください。

- ディレクトリ・サービスは特定の時刻にのみアクセスされるかどうか

- 読取り操作と書込み操作の可用性要件が異なるかどうか

- サービスが複数の地理的サイトにまたがっている場合に、これらのサイトのアクセス時間要件が異なるかどうか

- システムを保守のためにシャットダウンできるかどうか
その場合に許容できる最大の停止時間

- システムを移行中にシャットダウンできるかどうか

- 組織にとっての停止時間のコスト

高可用性ディレクトリ・サービスのデプロイに関する推奨事項は、第12章「高可用性デプロイメントの設計」を参照してください。

5.4 スケーラビリティ要件の定義

ディレクトリの進化に伴い、サポートする必要があるサービス・レベルが変わることがあります。システムをデプロイした後にサービス・レベルを上げることは、困難になる場合があります。したがって、初期設計で将来の要件を考慮する必要があります。

スケーラビリティ要件を定義するときは、次の点を考慮してください。

- エントリ・ボリュームの増加が見込まれるかどうか

- 今後数年以内に予想される新しいユーザーの数

- データ、ユーザーおよびクライアント・アプリケーションの、今後数年間に予想される増加率

- 予想される新しいビジネス・プロセスがあるかどうか

デプロイメントを途中で拡張する必要がないように、CPUの見積りを増やします。予想される拡張のマイルストンおよび時間の経過に伴って増大すると想定される負荷を検討して、マイルストンに到達するまでに十分な潜在処理能力を確保できるようにします。

5.5 セキュリティ要件の定義

セキュリティ要件については、別途説明する必要があります。これらの要件の詳細は、第7章「セキュリティ要件の特定」を参照してください。

5.6 潜在処理能力要件の定義

潜在処理能力要件を特定する場合は、ディレクトリ・サービスのピーク時の負荷条件を見積もります。次の点を考慮してください。

- すべてのクライアント・アプリケーションが実行されている場合の、Directory Serverへの同時接続の最大数

- 1台以上のサーバーで障害が発生した場合の、デプロイメント内の残りのサーバーへの負荷

5.7 運用性要件の定義

運用性要件の詳細は、第8章「管理および監視の要件の特定」を参照してください。

6 システムの特性のチューニングおよびハードウェアのサイズ設定

Directory Server Enterprise Editionのデプロイメントでは、最初に特定のシステム特性を定義する必要があります。この章では、デプロイメントの計画フェーズで対応する必要があるシステム情報について説明します。

この章の内容は、次のとおりです。

- ホスト・システムの特性

- ポート番号

- Directory Service Control Centerのハードウェアのサイズ設定

- Directory Proxy Serverのハードウェアのサイズ設定

- Directory Serverのハードウェアのサイズ設定

- Directory Server用のオペレーティング・システムのチューニング

- Directory Serverの物理的機能

- 全体的なパフォーマンスを改善するためのその他のヒント

- キャッシュ設定のチューニング

- パフォーマンスのための索引のチューニング

- 基本的なDirectory Serverのサイズ設定の例: ディスクおよびメモリー要件

6.1 ホスト・システムの特性

デプロイメントで使用されるホスト・システムを決定するときは、次の点を考慮してください。

- システムを単一のサーバー専用にするかどうか。

- システムでその他のアプリケーションを実行するかどうか、および、実行する場合、そのアプリケーションは何か。

- これらのアプリケーションで必要とされるシステムのリソースのパーセンテージはどのくらいか。

ホスト・システムが決定したら、トポロジ内の各ホストについてホスト名を選択します。各ホスト・システムが必ず静的IPアドレスを持つようにします。

ホスト・システムへの物理アクセスを制限します。Directory Server Enterprise Editionには数多くのセキュリティ機能が備えられていますが、ホスト・システムへの物理アクセスが制御されないと、ディレクトリのセキュリティが損なわれます。

Directory Serverインスタンスによってネットワークに対するネーミング・サービスが提供されない場合、またはデプロイメントにリモート管理が関与する場合、ネーミング・サービスおよびホストのドメイン名を適切に構成する必要があります。

6.2 ポート番号

設計時に、Directory ServerおよびDirectory Proxy Serverの各インスタンスにポート番号を選択します。可能な場合、本番環境へのディレクトリ・サービスのデプロイ後はポート番号を変更しないでください。

様々なサービスおよびコンポーネントに対し、個別のポート番号を割り当てる必要があります。

- Directory ServerおよびDirectory Proxy ServerのLDAPおよびLDAPSポート番号

- Directory ServerのDSMLポート番号

- Directory Service Control CenterおよびDSCCエージェントのポート番号

- Identity Synchronization for Windowsのポート番号

6.2.1 Directory ServerおよびDirectory Proxy ServerのLDAPおよびLDAPSポート番号

LDAP接続を受け入れるためのポート番号を指定します。LDAP通信の標準ポートは389ですが、その他のポートも使用できます。たとえば、サーバーを一般ユーザーとして起動できるようにする必要がある場合には、デフォルトが1389の権限のないポートを使用します。1024より小さいポート番号では権限付きアクセスが必要です。1024より小さいポート番号を使用する場合、特定のLDAPコマンドはrootとして実行する必要があります。

SSLベースの接続を受け入れるためのポート番号を指定します。SSLベースのLDAP (LDAPS)通信の標準ポートは636ですが、一般ユーザーとして実行する場合のデフォルトである1636など、他のポートを使用することもできます。たとえば、サーバーを一般ユーザーとして起動できるように、権限のないポートが必要な場合があります。

権限のないポートを指定し、かつ他のユーザーがアクセスできるシステム上にサーバー・インスタンスをインストールした場合、そのポートは別のアプリケーションにハイジャックされる危険にさらされる可能性があります。つまり、他のアプリケーションで同じアドレスとポートのペアにバインドすることが可能になります。この場合、不法なアプリケーションで、サーバー宛のリクエストを処理できる可能性があります。このようなアプリケーションを使用して、認証処理に使用されるパスワードを取得したり、クライアント・リクエストまたはサーバー・レスポンスを変更したり、DoS攻撃を実行することもできます。

サーバーがリスニングするIPアドレスのリストは、Directory ServerおよびDirectory Proxy Serverの両方で制限できます。Directory Serverには構成属性nsslapd-listenhostおよびnsslapd-securelistenhostがあります。Directory Proxy Serverでは、ldap-listenerおよびldaps-listener構成オブジェクト上にlisten-addressプロパティがあります。リスニングするインタフェースのリストを指定すると、他のプログラムではサーバーと同じポート番号を使用できなくなります。

6.2.2 Directory ServerのDSMLポート番号

Directory Serverでは、LDAPのリクエストを処理する以外に、Directory Service Markup Language v2 (DSML)で送信されたリクエストにも応答します。DSMLでも、クライアントでディレクトリ操作をエンコードできます。Directory Serverでは、同じアクセス制御とセキュリティ機能により、DSMLを他のリクエストと同様に処理します。

トポロジにDSMLアクセスが含まれる場合は、次のことを決定します。

- DSMLリクエストを受け取るための標準のHTTPポート。デフォルト・ポートは80です。

- SSLがアクティブ化されている場合、暗号化されたDSMLリクエストを受け取るための暗号化(HTTPS)ポート。デフォルト・ポートは443です。

- ホストおよびポートに付加された場合、クライアントでDSMLリクエストを送信するために使用する必要がある完全なURLを決定する相対URL。

DSMLの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDSML-over-HTTPサービスを有効にする方法に関する説明を参照してください。

6.2.3 Directory Service Control CenterおよびDSCCエージェントのポート番号

Directory Service Control Center (DSCC)は、WebブラウザからDirectory ServerおよびDirectory Proxy Serverインスタンスを管理するために使用できるWebアプリケーションです。サーバーがDSCCによって認識されるようにするには、そのサーバーをDSCCに登録する必要があります。登録されていないサーバーも、コマンドライン・ユーティリティを使用して管理できます。

DSCCは、サーバーがインストールされているシステムにあるDSCCエージェントと通信します。DSCCエージェントはネットワーク・トラフィックをそれらにルーティングして、それらが実行するためのフレームワークを提供します。

DSCCを使用してトポロジ内のサーバーを管理することを計画している場合は、次のポート番号を指定してください。

- DSCCがインストールされているシステムでDSCCにアクセスするための、暗号化されたHTTPSポート。デフォルト・ポートは8080です。

- サーバー・インスタンスがインストールされているシステムで、サーバーに対してローカルなDSCCエージェントにアクセスするための、DSCC用管理トラフィック・ポート(デフォルトは11162)。

- 構成情報をレプリケートする場合は、DSCCレジストリ・インスタンスのポート番号。詳細は、dsccsetupを参照してください。

すべてのコンポーネントが同じシステムにインストールされている場合も、DSCCではこれらのネットワーク・ポートを使用してエージェントと通信します。

6.2.4 Identity Synchronization for Windowsのポート番号

デプロイメントにMicrosoft Active Directoryとのアイデンティティの同期が含まれる場合は、Message Queueインスタンス用に、使用可能なポートが必要となります。このポートは、同期に関与する各Directory Serverインスタンスで使用可能である必要があります。Message Queue用のデフォルトの保護されていないポートは80で、デフォルトの保護ポートは443です。

また、デプロイメントを計画するときは、追加のインストールに関して、および構成に関して決定することも必要となります。Identity Synchronization for Windowsのインストールおよび構成の詳細は、Identity Synchronization for Windows 6インストール・ガイド、およびOracle Identity Synchronization for Windows 6.0インストレーションおよび構成ガイドを参照してください。

6.3 Directory Service Control Centerのハードウェアのサイズ設定

DSCCはWebアプリケーションとして実行され、Directory Serverの独自のローカル・インスタンスを使用して構成データを保管します。

DSCCを実行するための最小要件は、256MBのメモリーおよび100MBの空きディスク領域です。ただし、最適なパフォーマンスを得るには、DSCC専用の1GB以上のメモリーと、数GBの空きディスク領域のあるシステムでDSCCを実行してください。

6.4 Directory Proxy Serverのハードウェアのサイズ設定

Directory Proxy ServerはマルチスレッドJavaプログラムとして実行され、複数のプロセッサをまたいで拡張できるように構築されています。一般的に、使用可能な処理能力が大きいほど適切ですが、実際には、メモリーを追加したりディスクやネットワーク接続を高速化した方が、プロセッサを追加するよりもパフォーマンスが向上する場合があります。

6.4.1 仮想メモリーの構成

Directory Proxy Serverでは主に、処理中の情報を保持するためにメモリーを使用します。複数のデータ・ソースに対する仮想ディレクトリ・リクエストを処理するための複雑な集計では、一時的に余分なメモリーを使用する場合があります。データ・ソースのいずれかがLDIFファイルである場合、Directory Proxy Serverによって、そのデータ・ソースの表現がメモリー内に構築されます。ただし、大量のLDIFデータ・ソースを使用(非推奨のデプロイメント方法です)しないかぎり、数GBのメモリーをDirectory Proxy Server専用にすれば十分です。十分なメモリーが使用可能である場合には、Directory Proxy Server起動時のJava仮想マシンのヒープ・サイズを増やすことをお薦めします。たとえば、Java仮想マシンのヒープ・サイズを3GBに設定するには、次のコマンドを使用します。

$ dpadm set-flags instance-path jvm-args="-Xms3G -Xmx3G -XX:NewSize=2G -XX:MaxNewSize=2G -XX:+UseParNewGC -XX:+UseConcMarkSweepGC"

このコマンドで使用するいくつかのオプションは、Oracle Java仮想マシンに固有のオプションです。NewSizeおよびMaxNewSize値は、ヒープの2/3にすることをお薦めします。デフォルトのヒープ・サイズは1GBです。

6.4.2 ワーカー・スレッドおよびバックエンド接続の構成

Directory Proxy Serverを使用して、リクエストを処理するためにサーバーで保持するスレッドの数を構成できます。これは、number-of-worker-threadsで説明されているサーバー・プロパティnumber-of-worker-threadsを使用して構成します。目安として、50スレッドに、使用されるデータ・ソースごとに20スレッドを追加した数値に設定します。この数値が十分かどうかを判断するには、cn=Work Queue,cn=System Resource,cn=instance-path,cn=Application System,cn=DPS6.0,cn=Installed Product,cn=monitorで、Directory Proxy Serverの作業キューの状態を監視します。作業キューのoperationalStatusがSTRESSEDである場合、このことは、スレッドが不足状態である接続ハンドラで、新しいクライアント・リクエストを処理できないことを意味していることがあります。Directory Proxy Serverで追加のシステム・リソースを使用できる場合は、number-of-worker-threadsを増やすと役立つことがあります。

ワーカー・スレッドの数は、バックエンド接続の数に対しても適切なものである必要があります。バックエンド接続の数に対してワーカー・スレッドが多すぎる場合、受信接続を受け入れても、それをバックエンド接続に送信できません。このような状況は、一般的に、クライアント・アプリケーションにとって問題となります。

この状況が発生しているかどうかを判断するには、"Unable to get backend connections"というタイプのエラー・メッセージがログ・ファイルに含まれていないかチェックします。または、ロード・バランシングのcn=monitorエントリを確認します。そのエントリのtotalBindConnectionsRefused属性がnullでない場合、プロキシでは、バックエンド接続が不足したために、特定の操作を処理できませんでした。この問題を解決するには、バックエンド接続の最大数を増やします。各データ・ソースのバックエンド接続の数を構成するには、そのデータ・ソースのnum-bind-limit、num-read-limitおよびnum-write-limitプロパティを使用します。バックエンド接続の上限にすでに達した場合には、ワーカー・スレッドの数を減らします。

バックエンド接続の数に対してワーカー・スレッドが不足している場合は、サーバーのキュー内に多数の作業が蓄積し、新しい接続を処理できなくなる可能性があります。このため、クライアント接続がTCP/IPレベルで拒否され、LDAPエラーが返されない可能性があります。この状況が発生しているかどうかを判断するには、作業キューのcn=monitorエントリの統計を確認します。特に、readConnectionsRefusedおよびwriteConnectionsRefusedは低く保たれていることが適切です。また、maxNormalPriorityPeak属性の値も低く保たれていることが適切です。

6.4.3 Directory Proxy Serverのディスク領域

デフォルトでは、Directory Proxy Serverには、accessロギング用の最大1GBのローカル・ディスク領域と、errorsロギング用にさらに1GBのローカル・ディスク領域が必要です。Directory Proxy Serverでクライアント・アプリケーション・リクエストを処理するときに書き込まれるaccessログ・メッセージの数によって、ロギングがパフォーマンスのボトルネックになる可能性があります。ただし、通常、本番環境ではロギングを有効なままにする必要があります。このため、最高のパフォーマンスを実現するには、Directory Proxy Serverのログを、高速な専用ディスク・サブシステム上に配置します。ログ設定の調整手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの構成に関する説明を参照してください。

6.4.4 Directory Proxy Serverのネットワーク接続

Directory Proxy Serverはネットワーク集約型アプリケーションです。Directory Proxy Serverでは、クライアント・アプリケーション・リクエストごとに、複数の操作を異なるデータ・ソースに送信する可能性があります。Directory Proxy Serverとデータ・ソース間のネットワーク接続が高速で、十分な帯域幅があり、待機時間も短いことを確認してください。また、Directory Proxy Serverとクライアント・アプリケーション間の接続で予期されるトラフィック量を処理できることも確認してください。

接続が非常に頻繁にオープンおよびクローズされる場合は、TCPスタックの待機状態が継続する時間を1秒に短縮することを検討します。Solarisで、(スーパーユーザーとして)次のコマンドを使用します。

$ ndd -set /dev/tcp tcp_time_wait_interval 1000

その他のオペレーティング・システムについては、そのオペレーティング・システムのドキュメントを参照してください。

6.5 Directory Serverのハードウェアのサイズ設定

中規模から大規模のDirectory Serverデプロイメントに適したハードウェアを決定するには、本番時に提供することが予期されるデータに類似したデータと、予期されるクライアント・アプリケーションからのアクセス・パターンに類似したアクセス・パターンに基づいて、なんらかのテストを行う必要があります。特定のシステム用に最適化する場合には、システム・バス、周辺バス、入出力デバイスおよびサポートされているファイル・システムがどのように動作するかについて、理解しておく必要があります。Directory Serverをサポートするように入出力サブシステムの機能をチューニングするとき、その機能を活用するために、この知識が役立ちます。

この項では、Directory Serverのハードウェアのサイズ設定に対するアプローチ方法について説明します。ここでは、デプロイメントでDirectory Server専用として、いくつのプロセッサ、どれだけのメモリー、どれだけのディスク領域、およびどのようなタイプのネットワーク接続を使用するかを決定する場合の考慮事項を示します。

この項の内容は次のとおりです。

- チューニング・プロセス

- サンプル・ディレクトリ・データの作成

- 構成する項目とその理由

- クライアント・アプリケーション負荷のシミュレーション

- Directory Serverとプロセッサ

- Directory Serverとメモリー

- Directory Serverとローカル・ディスク領域

- Directory Serverとネットワーク接続性

- クライアントで使用可能なDirectory Serverリソースの制限

- Directory Serverにより使用されるシステム・リソースの制限

注意:

特に明記されていないかぎり、次の各項で説明されているサーバー・プロパティは、dsconfコマンドで設定できます。dsconfの使用方法の詳細は、dsconfを参照してください。

6.5.1 チューニング・プロセス

パフォーマンスのチューニングは、特定のデプロイメント要件が反映されるように、デフォルト構成を変更することを意味します。次のプロセス・フェーズのリストは、Directory Serverのチューニング時に考慮する主な項目を示しています。

目標の定義

デプロイメント要件に基づいて、特定の測定可能なチューニング目標を定義します。

次の質問事項を検討してください。

- どのアプリケーションがDirectory Serverを使用しますか。

- システム全体をDirectory Server専用にすることができますか。
システムで他のアプリケーションも実行されますか。

その場合、システムで実行される他のアプリケーションは何ですか。

- このデプロイメントによって何件のエントリが処理されますか。
エントリ件数はどのくらいになりますか。

- Directory Serverでは、1秒当たり何件の検索をサポートする必要がありますか。
予想される検索のタイプ

- Directory Serverでは、1秒当たり何件の更新をサポートする必要がありますか。
予想される更新のタイプ

- ピークの更新頻度および検索頻度はどのようになると予期されますか。
平均頻度はどれくらいになると予期されますか。

- デプロイメントでは、このシステム上で一括インポートによる初期化が繰り返し必要になりますか。
その場合、データのインポート頻度はどのくらいであると予期されますか。何件のエントリがインポートされますか。

どのようなタイプのエントリですか。

サーバーの実行中に初期化をオンラインで実行する必要があるかどうか

このリストはすべての要素を網羅しているわけではありません。使用する目標リストにすべての要素が網羅されていることを確認してください。

方法の選択

最適化の実装方法に関する計画を決定します。また、最適化の測定および解析方法に関する計画も決定します。

次の質問事項を検討してください。

- システムのハードウェア構成を変更できますか。

- すでにあるハードウェアを使用したり、サーバーが稼働しているオペレーティング・システムやDirectory Serverのみをチューニングする以外のことはできますか。

- 他のアプリケーションをどのようにシミュレートできますか。

- テスト用の代表的なデータのサンプルは、どのように生成しますか。

- 結果をどのように測定しますか。

- 結果をどのように解析しますか。

テストの実行

計画したテストを実行します。デプロイメントが大規模で複雑な場合、このフェーズに長い時間がかかる可能性があります。

結果の検証

テストした潜在的な最適化によって、プロセス開始時に定義した目標が達成されたかどうかをチェックします。

最適化によって目標が達成された場合は、その結果を文書化します。

最適化によって目標が達成されなかった場合は、Directory Serverをプロファイリングおよび監視します。

プロファイリングおよび監視

潜在的な変更を適用した後で、Directory Serverの動作をプロファイリングおよび監視します。

関係するすべての動作の測定値を収集します。

グラフ化および解析

プロファイリング中や監視中に観察した動作をグラフ化および解析します。証拠を見つけたり、追加のテストの必要性を示すパターンを発見するように努めます。

プロファイリングおよび監視フェーズに戻って、追加でデータを収集する必要がある可能性もあります。

調整およびチューニング

測定値の解析結果によって示される、追加的かつ潜在的な最適化を適用します。

テストの実行フェーズに戻ります。

結果の文書化

適用した最適化によってプロセス開始時に定義した目標が達成された場合には、その最適化を適切に文書化し、後でその最適化を容易に再現できるようにします。

6.5.2 サンプル・ディレクトリ・データの作成

どれだけのディスクやメモリーをDirectory Server専用にするかは、ディレクトリ・データによって異なります。LDIFに代表的なデータがすでにある場合は、デプロイメントのハードウェアをサイズ設定するとき、そのデータを使用します。ここで代表的なデータとは、デプロイメントで使用することが予期されるデータに対応するサンプル・データを意味し、デプロイメントで使用する実際のデータを意味するものではありません。実際のデータは、現実的なプライバシに関する配慮を必要とし、代表的なデータの生成に必要となる仕様に比べて桁違いに大きくなる場合があるため、テスト対象のすべてのケースを実施することが困難になることがあります。代表的なデータに含まれるエントリの平均サイズは、デプロイメント時に予期されるサイズに近く、その属性は、デプロイメント時に予期される値と同様の値を持ち、その数は、デプロイメント時に予期される比率と同様の比率で存在しています。

代表的なデータに基づいてなんらかの決定を下す場合には、予期される増加分を考慮します。容量計画においては、現在のデータのオーバーヘッド分を含めることをお薦めします。

代表的なデータをまだ用意していない場合は、makeldifコマンドを使用してサンプルLDIFを生成し、それをDirectory Serverにインポートできます。第4章「データ特性の定義」を参照すると、デプロイメントにおける代表的なデータがどのようなものかを決定する場合に役立ちます。makeldifコマンドは、Directory Server Resource Kitツールの1つです。

本番時に数百万件のエントリを提供することが予期されるデプロイメントでは、数百万件のエントリをテスト用にロードするのが理想的です。ただし、数百万件のエントリをロードすることは、最初の見積り目的としては現実的でない可能性もあります。まず、10,000件のエントリ、100,000件のエントリ、1,000,000件のエントリなど、代表的なデータのセットをいくつか作成し、それらをインポートし、そこで観察された結果に基づいて推定することで、追加のテストに必要となるハードウェアを見積もります。ハードウェア要件を見積もる場合は、複数のサーバーにレプリケートされるデータを準備します。

LDIFからDirectory Server内にディレクトリ・データをインポートすると、その結果として得られるデータベース・ファイル(索引を含む)は、LDIF表現よりも大きくなることに注意してください。データベース・ファイルはデフォルトで、instance-path/db/ディレクトリ下にあります。

6.5.3 構成する項目とその理由

Directory Serverのデフォルト構成設定は一般的な小規模デプロイメント向けに定義されたものであり、その目的は、この製品を容易にインストールおよび評価できるようにすることです。この項では、中規模から大規模のデプロイメントで調整する、いくつかの主な構成設定について説明します。中規模から大規模のデプロイメントでは、ユーザーの特定のデプロイメントに構成設定を適応させることで、パフォーマンスを大幅に改善できることがよくあります。

6.5.3.1 Directory Serverのデータベース・ページ・サイズ

Directory Serverでは、データの読み書きを行うとき、ページと呼ばれる固定長のデータ・ブロックを操作します。ページ・サイズを増やすことにより、1つのディスク操作で読み書きされるブロックのサイズが増大します。

ページ・サイズはエントリのサイズと関係し、パフォーマンスにとって不可欠の要素です。エントリの平均サイズがdb-page-size/4-24 (24はページごとのバイナリ・ツリー内部構造)より大きいことがわかっている場合は、データベース・ページ・サイズを増やす必要があります。データベースのページ・サイズは、ファイル・システムのディスク・ブロック・サイズと一致する必要もあります。

6.5.3.2 Directory Serverのキャッシュ・サイズ

Directory Serverは、クライアント・アプリケーションのリクエストにすばやく応答するように設計されています。Directory Serverでは、ディスクからディレクトリ・データが読み取られるまで待つ必要がないように、メモリー内にデータをキャッシュします。データベース・ファイル用、ディレクトリ・エントリ用およびLDIFからのディレクトリ・データのインポート用のキャッシュとして、どれだけのメモリーが使用されるかを構成できます。

物理メモリーにすべてのディレクトリ・データをキャッシュするのに十分な領域を使用できるハードウェア上で、Directory Serverを実行するのが理想的です。データが適切に収まるようにすることで、システムで動作に必要な物理メモリーを確保でき、かつ、ファイル・システムで、そのキャッシュ化や操作に必要な物理メモリーを確保できるようにする必要があります。一度データがキャッシュに書き込まれると、ディレクトリ・エントリが変更されないかぎり、Directory Serverではディスクに対してデータの読み書きを行う必要がなくなります。

デフォルトでは、エントリ・キャッシュは、サーバーによって、負荷に応じて完全に管理されます。エントリ・キャッシュ設定を変更する前に、デフォルト値を使用した場合のサーバーの動作を評価することをお薦めします。

Directory Serverでは64ビット・メモリー・アドレス指定をサポートしているため、64ビット・プロセッサでアドレス指定可能なサイズであるかぎり、どのくらい大きい合計キャッシュ・サイズでも処理できます。小規模から中規模のデプロイメントでは、多くの場合、すべてのディレクトリ・データをキャッシュ内に保持できるだけのメモリーを確保できます。ただし、大規模デプロイメントでは、すべてをキャッシュに保持することは、現実的でないか費用効率が高くない場合があります。

大規模デプロイメントでは、すべてをメモリーにキャッシュすると、副作用が発生する可能性があります。プロセスのメモリー・マップをトラバースしてデータを収集する、pmapコマンドなどのツールを実行すると、長時間にわたり、サーバー・プロセスが動かなくなる可能性があります。コア・ファイルが非常に大きくなるため、クラッシュ時にそれらをディスクに書き込むために数分かかる可能性があります。サーバーが突然停止した後で再起動した場合、起動時間が長くなることがあります。また、Directory Serverがチェックポイントに到達し、ダーティ・キャッシュ・ページをディスクにフラッシュする必要がある場合には、Directory Serverが一時的に停止し、応答しなくなる可能性もあります。キャッシュが非常に大きい場合はこの一時停止も非常に長くなり、Directory Serverが停止しているものと監視ソフトウェアによって判断される可能性があります。

オペレーティング・システム・レベルの入出力バッファにより、パフォーマンスが向上する場合があります。非常に大きいバッファは、少ないデータベース・キャッシュを補うことができます。

キャッシュおよびキャッシュ設定の詳細は、「キャッシュ設定のチューニング」を参照してください。キャッシュ・サイズのチューニングの詳細は、Directory Serverのキャッシュ・サイズ設定の基本(http://blogs.sun.com/DirectoryManager/resource/ds_cache_sizing.pdf)を参照してください。

6.5.3.3 Directory Serverの索引作成

Directory Serverでは、ディレクトリ・エントリの属性値に対する索引を作成することで、それらの属性値の検索を高速化します。様々な方法で索引が作成されるよう属性を構成できます。たとえば、索引によって、ある属性が値を持っているか、特定の値に等しい値を持っているかまたは特定の部分文字列を含む値を持っているかを、Directory Serverですばやく判別できるようになります。

索引によって検索時のパフォーマンスが向上する可能性がありますが、書込みパフォーマンスに影響する可能性もあります。ある属性の索引が作成されると、Directory Serverではその属性の値が変更されるたびに索引を更新する必要があります。

Directory Serverでは、索引データがファイルに保存されます。構成する索引が多いほど、必要なディスク領域も多くなります。Directory Serverの索引およびデータ・ファイルはデフォルトで、instance-path/db/ディレクトリ下にあります。

索引作成および索引設定の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第9章「Directory Serverの索引作成」を参照してください。

6.5.3.4 Directory Serverの管理ファイル

Directory Serverのいくつかの管理ファイルは、サイズが非常に大きくなる可能性があります。これらのファイルには、ディレクトリ・データを含むLDIFファイル、バックアップ、コア・ファイルおよびログ・ファイルなどがあります。

デプロイメントによっては、Directory Serverデータのインポートおよび補助バックアップの両方の用途でLDIFを使用できます。標準テキスト形式のLDIFを使用すると、バイナリ・データだけでなく文字列もエクスポートできます。大規模デプロイメントの場合、LDIFによって多くのディスク領域が使用されることがあります。たとえば、平均サイズが2KBのエントリが1千万件含まれているディレクトリは、LDIF表現ではディスク上で20GBを使用します。この形式を補助バックアップとして使用する場合は、このサイズのLDIFファイルを複数個維持することがあります。

バイナリのバックアップ・ファイルも、少なくとも保管のためにどこか他の場所に移動されるまでは、ディスク領域を使用します。Directory Serverユーティリティによって生成されるバックアップ・ファイルは、ディレクトリ・データベース・ファイルのバイナリ・コピーで構成されます。大規模デプロイメントの場合は別の方法として、Directory Serverを凍結モードにしてから、ファイル・システムのスナップショットを取ることもできます。いずれにしても、バックアップに使用可能なディスク領域が必要です。

Directory Serverではデフォルトで、ログ・メッセージをinstance-path/logs/accessおよびinstance-path/logs/errorsに書き込みます。Directory Serverにはデフォルトで、accessロギング用の1GBのローカル・ディスク領域およびerrorsロギング用にさらに200MBのローカル・ディスク領域が必要です。

Directory Serverロギングの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第10章「Directory Serverのロギング」を参照してください。

6.5.3.5 Directory Serverのレプリケーション

Directory Serverでは、ディレクトリ・データをレプリケートすることで、デプロイメント内のサーバーの可用性を高め、サーバー間のロード・バランシングを行うことが可能になります。Directory Serverを使用すると、複数の読み書き(マスター)レプリカを一緒にデプロイできます。

サーバーではこれを可能にするために、内部的にディレクトリ・データへの変更を追跡します。同じデータが複数の読み書きレプリカ上で変更されても、Directory Serverではその変更をすべてのレプリカ上で正しく解決できます。これらの変更を追跡するためのデータは、レプリケーション時に必要とされなくなるまで、保持しておく必要があります。変更は、パージ遅延によって指定された期間のみ保持されます(デフォルト値は7日間です)。ディレクトリ・データ、特に、大きい複数値属性に多数の変更が加えられた場合、このデータは非常に大きくなることがあります。

増大のレベルは様々な要素によって異なるため、可能性のあるデータの増大量を計算するための汎用的な数式はありません。一般的な変更をテストして増大量を測定することが、最適なアプローチとなります。次の要素は、エントリの変更に伴うデータの増大に影響を及ぼします。

- 変更対象のエントリのタイプと属性のタイプ。
複数値属性では増大量が大きくなります。属性値が小さい場合は、増大量はより顕著になります。

- エントリに課されるワークロード。
エントリの追加や削除を行うと、増大量が大きくなります。属性値を追加すると、属性値を置き換えた場合よりも増大量が大きくなります。

- 変更対象のエントリ数および各エントリ内の変更対象の属性の数。

- データベース・ページのサイズ。
非常に多数の変更を加えた場合、特定のエントリがデータベース・ページ・サイズよりも大きくなる可能性があります。

パージ遅延の期間が過ぎ、かつエントリがもう一度変更されるまで、レプリケーションのメタデータはエントリ内に保持されたままになっていることに注意してください。

Directory Serverのレプリケーションの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。

6.5.3.6 Directory Serverのスレッドおよびファイル記述子

Directory Serverはマルチスレッド・プロセスとして実行され、マルチプロセッサ・システム上で拡張できるように設計されています。Directory Serverで操作を処理するために起動時に作成されるスレッドの数を構成できます。デフォルトでは、Directory Serverにより30個のスレッドが作成されます。値を設定するには、dsconfコマンドを使用してサーバー・プロパティthread-countを調整します。

スレッドをできるだけビジーに保ち、かつ、多数のスレッドを処理することが必要になることで、undo処理のオーバーヘッドが発生することがないようにすることがポイントです。すべてのディレクトリ・データがキャッシュ内に収まるかぎり、プロセッサ数の2倍に予期される同時更新処理数を加えた値をthread-countに設定すると、パフォーマンスが向上することが多くなります。多量のディレクトリ・データ・セットの一部のみがキャッシュ内に収まる場合には、Directory Serverのスレッドが、ディスクからのデータ読取りを待機することが頻繁に必要になります。この場合は、使用可能なプロセッサ数の16倍を上限として、スレッド数を非常に大きくすると、パフォーマンスを改善できることがあります。

Directory Serverではファイル記述子を使用して、クライアント・アプリケーションのオープン接続に関係するデータを保持します。デフォルトでは、Directory Serverでは最大1024個のファイル記述子が使用されます。値を設定するには、dsconfコマンドを使用して、サーバー・プロパティfile-descriptor-countを調整します。too many fds openというメッセージがerrorsログに含まれている場合には、file-descriptor-countを増やすことでパフォーマンスが向上する可能性があります(Directory Serverで追加のファイル記述子をオープンすることがシステムによって許可されていると仮定した場合)。

file-descriptor-countプロパティはWindowsには適用されません。

6.5.3.7 Directory Serverの規模の増大

多くの場合、Directory Serverは、デプロイされた後に使用量が増加します。デプロイメントを成功させ、一貫して高レベルのサービスを継続的に提供するには、増加に備えることが重要となります。将来的に予期される規模の増大も含めた要件定義を行い、現時点で必要なシステムよりも大規模で強力なシステムを計画してください。

ディレクトリ・サービスの規模の増大が、急激に、または突然、必要になることがあります。たとえば、ある組織用にサイズ設定されたディレクトリ・サービスが別の組織のディレクトリ・サービスとマージされる場合などが、そのケースに該当します。規模増大に前もって備え、予期されることを明示的に特定することによって、予期される増大が計画された容量を超過するかどうかを事前に把握できるため、急激な規模増大や突然の規模増大に、より適切に対処できるようになります。

6.5.3.8 最重要のチューニング・ヒント

基本的な推奨事項を次に示します。これらの推奨事項はほとんどの状況に適用されます。ここに示した推奨事項は基本的に有効ですが、実際のデプロイメントへの影響を理解しないでこれらの推奨事項を適用することは避けてください。この項はそのまま適用するのではなく、チェックリストとして使用してください。

1. キャッシュ・サイズを調整します。
理想的なサーバーでは、使用可能な物理メモリーが十分に存在し、Directory Serverにより使用されるすべてのキャッシュを保持できます。さらに、ある適切な量の追加物理メモリーが、将来の規模増大を考慮して使用可能になっています。十分な物理メモリーが使用可能な場合には、エントリ・キャッシュ・サイズを十分に大きい値に設定し、ディレクトリ内のすべてのエントリを保持できるようにします。そのような値を構成するための標準的な方法は、テストを実行してから、その結果を使用してnsslapd-cachesizeパラメータを設定することです。

たとえば、サーバーで1秒当たり20000回の操作を処理できる場合、エントリ・キャッシュには30000件から40000件のエントリを保持する必要があります。このような状況下では、エントリ・キャッシュはサーバー上の負荷の1.5から2倍の範囲内にある必要があります。負荷のパターンが変化した場合は、新しい値を設定する必要があります。

entry-cache-size接尾辞プロパティを使用します。db-cache-sizeプロパティを使用して、すべての索引を保持するために十分なデータベース・キャッシュ・サイズを設定します。dn-cache-sizeまたはdn-cache-countプロパティを使用して、DNキャッシュのサイズを制御します。

設定可能なキャッシュ・サイズ・プロパティの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』またはserverのマニュアル・ページを参照してください。エントリ・キャッシュの詳細は、Oracle Directory Server Enterprise Editionリファレンスを参照してください。

2. 索引作成を最適化します。

1. 不要な索引を削除します。予期されるリクエストをサポートするための索引を追加します。
場合によっては、新しいアプリケーションからのリクエストをサポートする索引を追加することもできます。索引の追加、削除または変更は、Directory Serverの稼働中に実行できます。たとえば、dsconf create-indexやdsconf delete-indexなどのコマンドを使用します。

システム索引を削除しないように注意してください。システム索引のリストは、Oracle Directory Server Enterprise Editionリファレンスのシステム索引およびデフォルト索引に関する説明を参照してください。

ユーザーが索引に変更を加えると、Directory Serverにより徐々にデータの索引が作成されます。dsconf reindexコマンドを使用して、Directory Serverで強制的に索引を再生成することもできます。

2. 索引を使用する検索のみを許可します。
索引を使用しない検索によって、サーバーのパフォーマンスに大幅な悪影響が発生する場合があります。索引を使用しない検索では、サーバー・リソースを大量に消費する可能性もあります。

require-index-enabled接尾辞プロパティをonに設定することで、索引を使用しない検索を拒否するようサーバーに強制することを検討します。

3. all-ids-thresholdプロパティを使用して、索引キー当たりの値の最大数を調整します。

3. idsktuneコマンドからの推奨事項に従って、基盤となるオペレーティング・システムをチューニングします。詳細は、idsktuneを参照してください。

4. 操作制限を調整します。
操作制限を調整できることで、Directory Serverによって過度のリソースが単一の操作に使用されることが防止されます。より多くの機能を必要とするクライアント・アプリケーションには、一意のバインドDNを割り当て、それらの一意のバインドDNに固有のリソース制限を設定することを検討します。

5. ディスク・アクティビティを分散します。
大量の更新をサポートするデプロイメントでは特に、Directory Serverに非常に多くのディスク入出力が集中する可能性があります。可能な場合は、個別のコントローラを使用して、この負荷を複数のディスクに分散することを検討します。

6. 不要なロギングを無効にします。
ディスク・アクセスはメモリー・アクセスよりも低速です。したがって、過度のロギングはパフォーマンスに悪影響を及ぼす可能性があります。読取り専用のサーバー・インスタンス上など、監査ロギングが必要ない場合にそのロギングをオフにしておくことで、ディスクの負荷を減らしてください。エラー・ログを使用して問題のトラブルシューティングを行わないときには、エラー・ロギングを最小レベルにしておきます。また、ログ・ファイルを専用のディスク上や、レプリケーション変更ログ用のディスクなどの、使用頻度の低いディスク上に配置することによっても、ロギングの影響を軽減できます。

7. 多数の更新をレプリケートする場合には、適切なレプリケーション承諾プロパティを調整することを検討します。
プロパティは、transport-compression、transport-group-sizeおよびtransport-window-sizeです。

8. Solarisシステムでは、データベース・ホーム・ディレクトリをtmpfsファイル・システムに移動します。
db-env-pathプロパティで指定されるデータベース・ホーム・ディレクトリは、Directory Serverによりデータベース・キャッシュ・バッキング・ファイルが格納される場所を示します。データ・ファイルはデフォルトで、instance-path/db下に存在し続けます。

データベース・キャッシュ・バッキング・ファイルをtmpfsファイル・システム上に置くことで、システムでデータベース・キャッシュ・バッキング・ファイルがディスクに繰り返しフラッシュされなくなります。これにより、更新時のパフォーマンスのボトルネックが回避されます。場合によっては、検索時のパフォーマンスのボトルネックも回避されます。データベースのキャッシュ・メモリーはDirectory Serverのプロセス空間にマップされます。システムでは基本的に、tmpfsファイル・システム内のキャッシュ・メモリーおよびバッキング・ファイルの保持に使用されるメモリーを共有します。したがって、必要メモリー領域については基本的にコストなしに、パフォーマンスを改善できます。

この最適化に関連する主なコストは、ホスト・マシンを再起動した後にデータベース・キャッシュを再構築する必要があることです。ソフトウェアまたはハードウェアでの障害発生後にのみ再起動が発生することが予期される場合、このコストはおそらく回避できません。そのような障害が発生した場合は、いずれにしてもデータベース・キャッシュを再構築する必要があります。

9. ソフトウェアまたはハードウェアでの障害が発生したときに、更新が失われても問題がない場合には、トランザクション・バッチを有効にします。
トランザクション・バッチを有効にするには、サーバー・プロパティdb-batched-transaction-countを設定します。

トランザクション・ログが更新されるたびに、更新データが失われないように、同期操作が続いて実行されます。トランザクション・バッチを有効にすると、複数の更新がまとめられた後、トランザクション・ログに書き込まれます。同期操作は、バッチ全体がトランザクション・ログに書き込まれるときにのみ、実行されます。したがって、トランザクション・バッチによって、更新時のパフォーマンスを大幅に改善できます。この改善にはトレード・オフが伴います。そのトレード・オフとは、クラッシュした時点でトランザクション・ログにまだ書き込まれていない更新データが失われることです。

注意:

トランザクション・バッチを有効にすると、ソフトウェアまたはハードウェアでの障害発生時に最大db-batched-transaction-count - 1件の更新が失われます。この損失が発生するのは、Directory Serverでは、バッチが一杯になるまで間か1秒間のどちらか短い方の期間待機した後で、内容をトランザクション・ログ(すなわちディスク)にフラッシュするためです。

更新が失われると問題がある場合は、この最適化を使用しないでください。

10. 整合性チェックを遅延させるように、参照整合性プラグインを構成します。
参照整合性プラグインでは、エントリが変更されたりディレクトリから削除された場合に、それらのエントリへのすべての参照が確実に更新されるようにします。この処理はデフォルトでは、削除操作に対するレスポンスがクライアントに返される前に、同期的に実行されます。プラグインを構成して、この更新が非同期で実行されるようにすることができます。ref-integrity-check-delayサーバー・プロパティを使用します。

6.5.4 クライアント・アプリケーション負荷のシミュレーション

Directory Serverのパフォーマンスを測定するには、サーバーを準備した後、本番において予期されるタイプのクライアント・アプリケーション・トラフィックをそのサーバーに適用します。本番で発生するクライアント・アプリケーションのアクセス・パターン・タイプの再現性が高いほど、ハードウェアのサイズ設定およびDirectory Serverの構成をより適切に実行できます。

Directory Server Resource Kitには、基本的なテストのために使用可能なauthrate、modrateおよびsearchrateコマンドが含まれています。これらのコマンドにより、使用するディレクトリ・サービスでサポート可能なバインド頻度、変更頻度および検索頻度を測定できます。

SLAMDを使用して、複雑で現実的なクライアント・アクセスのシミュレーション、測定およびグラフ化を行うこともできます。SLAMD分散負荷生成エンジン(SLAMD)は、ネットワーク・ベースのアプリケーションのパフォーマンスについて負荷テストを実行し、解析するために設計されたJavaアプリケーションです。これは、LDAPディレクトリ・サーバーのパフォーマンスについてベンチマークを実行し、分析するために、Sun Microsystems, Inc.によって開発されました。SLAMDは、OSI認定オープン・ソース・ライセンスであるSun Public Licenseに基づいて、オープン・ソース・アプリケーションとして使用できます。SLAMDについては、http://www.slamd.com/を参照してください。SLAMDは、java.netプロジェクトでも提供されています。https://slamd.dev.java.net/を参照してください。

6.5.5 Directory Serverとプロセッサ

Directory Serverは複数のプロセッサのあるシステム上で動作するように開発されたマルチスレッド・プロセスであり、そのパフォーマンスは、一般的に、専用のプロセッサの数が増加すると、線形的に向上します。多数のプロセッサが搭載されたシステム上でDirectory Serverを実行する場合、Directory Serverによってサーバー操作を処理するために起動されるスレッドの数を表すサーバー・プロパティthread-countを、dsconfコマンドを使用して調整することを検討します。

ただし、特定のディレクトリ・デプロイメントでは、プロセッサを追加してもパフォーマンスに大きく影響しない場合があります。検索、索引作成およびレプリケーションで要求の厳しいパフォーマンス要件を扱うときは、解決策の一部として、ロード・バランシングやディレクトリ・プロキシなどの技術を検討します。

6.5.6 Directory Serverとメモリー

次の要素は、必要なメモリーの量に大きく影響を及ぼします。

- Directory Serverのデータベース・キャッシュ、エントリ・キャッシュおよびインポート・キャッシュの設定

- ピーク時のレプリケーション負荷

- ピーク時のクライアント・アプリケーション負荷

- file-descriptor-countおよびthread-countのサーバー設定

- オペレーティング・システム、システム上で実行される他のアプリケーションおよびシステム管理アクティビティのオーバーヘッド

Directory Serverの実行に必要なメモリーのサイズを見積もるには、Directory Server Resource KitコマンドやSLAMDなどによって生成されたアプリケーション負荷を含む、本番と同様の負荷のかかったシステム上で、特定のDirectory Server構成で必要とされるメモリーを見積もります。

Directory Serverプロセスのサイズを測定する前に、サーバーを起動した後しばらく待ち、通常処理中またはピーク処理中と同様にエントリ・キャッシュが満たされるようにします。キャッシュ・メモリーに、すべて格納できる領域がある場合は、ディレクトリ内のすべてのエントリを読み取ってエントリ・キャッシュを満たすことで、このDirectory Serverのウォーム・アップ期間を短縮できます。キャッシュ・メモリーに、すべて格納できる領域がない場合には、通常処理またはピーク処理のパターンを使用して、そのパターンに応じてキャッシュが満たされるまで、クライアント・アクセスのシミュレーションをしばらく実行します。

サーバーが平衡状態になった後、SolarisやLinux上のpmapまたはWindowsタスク・マネージャなどのユーティリティを使用して、Directory Serverプロセス(UNIXシステムの場合はns-slapd、Windowsシステムの場合はslapd.exe)で使用されているメモリーを測定できます。詳細は、pmap(1)のマニュアル・ページを参照してください。使用するメモリーの量を決定する前に、通常処理中およびピーク処理中の両方のプロセス・サイズを測定します。

見積りには、システム管理に必要なメモリーと、システム自体に必要なメモリーの量を必ず追加します。オペレーティング・システムのメモリー要件は、システムの構成によって大幅に異なる場合があります。したがって、使用するオペレーティング・システムの実行に必要なメモリーは、実験的に見積もる必要があります。システムのチューニングが完了した後、見積りに対するメモリー使用量を監視します。SolarisのvmstatおよびsarコマンドやWindowsのタスク・マネージャなどのユーティリティを使用して、メモリー使用量を測定できます。

Directory Serverを実行するときに、パフォーマンスに悪影響を及ぼす継続的なページ・スワッピングが発生しないだけの量以上のメモリーを割り当ててください。Solarisシステム用として別途入手可能なサポート対象外のMemToolなどのユーティリティは、メモリーが実行中のアプリケーションによってどのように使用され、それらのアプリケーションにどのように割り当てられているかを監視する場合に役立つ可能性があります。

システムに追加のメモリーを搭載できないが、継続的なページ・スワッピングが引き続き発生する場合は、データベース・キャッシュやエントリ・キャッシュのサイズを減らします。heap-high-threshold-sizeおよびheap-low-threshold-sizeサーバー設定を使用してメモリーの使用量を調整することもできますが、ヒープしきい値メカニズムは最後の手段と考えてください。Directory Serverでヒープ・メモリーを解放するために他の操作を遅延することが必要になると、パフォーマンスが低下します。

Red Hat Linuxシステムの場合、/proc/sys/vm/swappinessパラメータを調整して、カーネルでどの程度積極的にメモリーをスワップ・アウトするかをチューニングできます。swappinessが高いことは、カーネルによるスワップ・アウトが大量になることを意味し、swappinessが低いことは、カーネルがスワップ・スペースを使用しないようにすることを意味します。したがって、swappiness設定値を小さくすると、カーネルがより多くのサーバー・プロセスをメモリーに保持することによって、スワップ・アウトするまでの時間が長くなるため、ディレクトリ・パフォーマンスが向上する場合があります。システムが単一のDirectory Serverインスタンス専用である場合は、swappinessをゼロに設定します。システムにおいて、複数の負荷の大きい処理や複数のDirectory Serverの並列インスタンスを実行する場合は、swappinessの様々な設定を使用してディレクトリ・パフォーマンスをテストすることを検討します。

6.5.7 Directory Serverとローカル・ディスク領域

ディスク使用とI/Oの能力は、パフォーマンスに大きく影響します。多数の変更をサポートするデプロイメントでは、特に、ディスク・サブシステムがI/Oのボトルネックになる可能性があります。この項では、Directory Serverインスタンスの全体的なディスク容量を見積もるために推奨される方法について説明します。

注意:

Directory Serverやそれによりアクセスされるデータをネットワーク・ディスク上にインストールしないでください。

Directory Serverソフトウェアでは、ネットワークに接続されたストレージをNFS、AFSまたはSMB経由で使用することをサポートしません。構成、データベースおよび索引ファイルはすべて、インストール後も、常にローカル・ストレージ上に配置する必要があります。ログ・ファイルはネットワーク・ディスク上に格納できます。

次の要素は、必要なローカル・ディスク領域に大きく影響を及ぼします。

- ディレクトリ・エントリの数

- エントリの平均サイズ

- サーバー・データベースのページ・サイズの設定(ディレクトリ・データをインポートする場合)
データベースのページ・サイズを調整するには、nsslapd-db-page-size属性を設定します。詳細は、「Directory Serverのデータベース・ページ・サイズ」を参照してください。

- ディレクトリ・データ上で維持される索引の数

- 格納されるLDIF、バックアップ、ログおよびコア・ファイルのサイズ

索引の設定、データベースのページ・サイズの調整およびディレクトリ・データのインポートが完了したら、instance-path/の内容のサイズを読み取り、それに予期されるLDIF、バックアップ、ログおよびコア・ファイルのサイズを追加することで、インスタンスに必要なディスク容量を見積もることができます。また、特に、ピーク処理中に、測定したサイズがどのくらい増加することが予期されるかを見積もります。デバッグ目的で、ログ・レベルを上げたり、ログ・サイズを増やすことが必要になった場合に備え、必ず、数GBの追加領域をerrorsログ用として残しておきます。

ディレクトリ・データに必要なディスクの見積りは、推定によって取得できる場合があります。本番時に予期されるデータと同量のデータを使用してDirectory Serverに負荷をかけることが現実的ではない場合には、「サンプル・ディレクトリ・データの作成」に示したように、より小さいサンプル・データ・セットに基づいて推定します。使用するディレクトリ・データの量が本番時より少ない場合、他の測定値についても推定する必要があります。

ローカル・ディスクがどのくらい高速である必要があるかは、次の要素によって決定されます。

- レプリケーション・トラフィックの量など、維持される更新のレベル

- ディレクトリ・データが主にキャッシュ内またはディスク上のどちらに存在するか

- アクセス・ロギングとエラー・ロギングで使用するログ・レベルおよび監査ログを有効にするかどうか

- ディレクトリ・データ、ログおよびトランザクション・ログ(更新用)を個別のディスク・サブシステムに配置できるかどうか

- Directory Serverがオンラインまたはオフラインのいずれの状態のときにバックアップが実行されるか

通常の運用環境では、使用するディスクは飽和しないようにしてください。Solaris iostatコマンドなどのツールを使用すると、潜在的なI/Oのボトルネックを特定できます。

ディスクのスループットを増やすには、複数のディスク・サブシステムにファイルを分散します。トランザクション・ログ(dsconf set-server-prop db-log-path:/transaction/log/path)、データベース(dsconf create-suffix --db-path /suffix/database/path suffix-name)およびログ・ファイル(dsconf set-log-prop path:/log/file/path)にそれぞれ専用のディスク・サブシステムを割り当てることを検討します。さらに、Solaris tmpfsファイル・システムなど、使用可能なメモリーが使い果たされた場合にのみファイルがディスクにスワップされる、メモリーベースのファイル・システム上に、データベース・キャッシュ・ファイルを配置することを検討します(たとえば、dsconf set-server-prop db-env-path:/tmp)。メモリーベースのファイル・システム上にデータベース・キャッシュ・ファイルを配置する場合には、そのファイル・システムの全体がメモリー内に保持されるだけの領域が、システムで不足しないようにしてください。

スループットをさらに増やすには、複数のディスクをRAID構成で使用します。Sun StorEdge製品で提供されているような、大容量の不揮発性I/Oバッファや高パフォーマンスのディスク・サブシステムによって、Directory Serverのパフォーマンスおよび稼働時間を大幅に改善できます。Solaris 10システムの場合、ZFSを使用することによっても、パフォーマンスを改善できます。

6.5.8 Directory Serverとネットワーク接続性

Directory Serverはネットワーク集約型アプリケーションです。次の式を使用して、理論的な最大スループットを見積もることができます。この式ではレプリケーションのトラフィックが考慮されていないことに注意してください。

max. throughput = max. entries returned/second x average entry size

Directory Serverではピーク時に毎秒5000件の検索に応答する必要があり、またサーバーからは検索ごとに1つのエントリが返される場合を考えます。エントリの平均サイズは2000バイトです。理論的な最大スループットは、レプリケーションを考慮しない場合、10MBつまり80メガビットになります。80メガビットは、多くの場合、単一の100メガビットEthernetアダプタで実現可能なスループットよりも大きくなります。Directory Serverインスタンスのネットワーク可用性を改善するには、システムにより高速な接続を装備するか、複数のネットワーク・インタフェースを装備します。Directory Serverでは、同一プロセス内で複数のネットワーク・インタフェースでのリスニングが可能です。

注意:

前述の例では、クライアント・アプリケーションでは、ディレクトリを読み取ったり検索するときに、すべての属性を要求すると想定していました。一般的に、必要な属性のみが要求されるように、クライアント・アプリケーションを設計する必要があります。

広域ネットワーク上でマルチマスター・レプリケーションを計画する場合には、その構成をテストし、その接続により最小限の待機時間とゼロに近いパケット損失で十分なスループットが提供されることを確認します。レプリケーションの速度は、長い待機時間および大量のパケット損失の両方によって低下します。さらに、レプリケーション・トラフィックがロード・バランサを通過するようなトポロジは避けてください。

6.5.9 クライアントが使用可能なDirectory Serverリソースの制限

Directory Serverのデフォルト構成では、クライアント・アプリケーションで必要以上のDirectory Serverリソースを使用できるようになっています。

次のようなリソースの使用法により、ディレクトリのパフォーマンスに悪影響が及ぶ可能性があります。

- 多数の接続をオープンした後に、アイドル状態や未使用状態のままにすること

- 索引を使用しない高コストの検索の不必要な起動

- 計画外の巨大なバイナリ属性値の格納

デプロイメント状況によっては、デフォルト構成を変更することが好ましくない場合があります。Directory Serverのチューニングが不可能なデプロイメントでは、Directory Proxy Serverを使用することで、リソースを制限し、DoS攻撃から保護します。

デプロイメント状況によっては、Directory Serverの1つのインスタンスによって、ユーザー・メール・アプリケーションなどのディレクトリ・クライアントやメッセージング・サーバーなどの、クライアント・アプリケーションをサポートすることが必要になります。そのような状況では、バインドDNベースのリソース制限を使用することで、ディレクトリ集約型アプリケーションに対して個別の制限を引き上げることを検討します。個々のアカウントの制限を調整するには、その個別のエントリ上の属性nsSizeLimit、nsTimeLimit、nsLookThroughLimitおよびnsIdleTimeoutを設定します。個々のアカウントに対するリソース制限の制御方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の各クライアント・アカウントのリソース制限の設定に関する説明を参照してください。

表6-1では、リソース制限のグローバル値を設定するパラメータについて説明します。表6-1の制限は、Directory Managerユーザーには適用されないため、クライアント・アプリケーションがDirectory Managerユーザーとして接続することがないようにしてください。

表6-1 クライアント・アプリケーション専用のリソースに関するチューニング推奨事項

チューニング・パラメータ

説明

サーバー・プロパティ

idle-timeout

クライアント接続のアイドル状態が何秒間続いた場合に、その接続をDirectory Serverによってクローズするかを設定します。ここで、アイドル状態とは、接続がオープンしたまま、操作がリクエストされない状態を意味します。デフォルトでは、時間制限は設定されません。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

メッセージング・サーバーなどの一部のアプリケーションでは、トラフィックが少ないときにはアイドル状態のままであるもののクローズしない必要がある、一連の接続をオープンする場合があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。

いずれの場合も、オープンしていることを他のアプリケーションが予期している接続をクローズしないように、この値を十分大きく設定するとともに、接続を不必要にアイドル状態のままにできないように、この値を十分小さく設定します。たとえば、これを7200秒、つまり2時間に設定することを検討してください。

属性

dn: cn=configのnsslapd-ioblocktimeout

クライアント接続の停止が何ミリ秒間続いた場合に、その接続をDirectory Serverによってクローズするかを設定します。ここで、停止されているとは、クライアントに出力を送信するとき、またはクライアントから入力を読み取るときに、サーバーがブロックされることを意味します。

この属性を設定するには、ldapmodifyコマンドを使用します。

特に、DoS攻撃にさらされるDirectory Serverインスタンスの場合は、この値をデフォルトの1,800,000ミリ秒つまり30分より小さくすることを検討してください。

サーバー・プロパティ

look-through-limit

検索時に一致するかどうかをチェックする候補エントリの最大数を設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

メッセージング・サーバーなどの一部のアプリケーションでは、ディレクトリ全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。

いずれにしても、この値をデフォルトの5000エントリより小さいが、search-size-limitのしきい値は下回らない値に設定することを検討してください。

属性

dn: cn=configのnsslapd-maxbersize

基本エンコーディング・ルール(BER)に従ってエンコードされたASN.1受信メッセージの最大サイズを、バイト単位で設定します。Directory Serverでは、この制限よりも大きいエントリを追加するリクエストは拒否されます。

この属性を設定するには、ldapmodifyコマンドを使用します。

ディレクトリ・データの最大エントリ・サイズを正確に予測できる場合には、この値をデフォルトの2097152つまり2MBから、予期される最大ディレクトリ・エントリのサイズに変更することを検討してください。

更新に対する2番目に大きいサイズ制限は、トランザクション・ログ・ファイルのサイズnsslapd-db-logfile-sizeで、これはデフォルトで10MBです。

サーバー・プロパティ

max-threads-per-connection-count

クライアント接続当たりの最大スレッド数を設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

メッセージング・サーバーなどの一部のアプリケーションでは、一連の接続をオープンし、それらの各接続上で多数のリクエストを発行する場合があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。

一部のアプリケーションにより1つの接続で多数のリクエストが実行されることが予期される場合には、この値をデフォルトの5より大きく10より小さい値に増やすことを検討してください。通常は、1接続当たり10個を超えるスレッドを指定しないでください。

サーバー・プロパティ

search-size-limit

検索リクエストに応答してDirectory Serverから返されるエントリの最大数を設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

メッセージング・サーバーなどの一部のアプリケーションでは、ディレクトリ全体を検索する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。

いずれにしても、この値をデフォルトの2000エントリより小さい値に設定することを検討してください。

サーバー・プロパティ

search-time-limit

Directory Serverにおいて1つの検索リクエストの処理に最大何秒使用できるかを設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

メッセージング・サーバーなどの一部のアプリケーションでは、非常に大規模な検索を実行する必要がある可能性があります。この場合、そのアプリケーションをサポートする専用のレプリカを用意するのが理想的です。それが不可能な場合には、バインドDNベースの個別制限を検討してください。

いずれにしても、この値は、デプロイメント要件を満たす範囲内でできるだけ小さく設定してください。デフォルト値の3600秒つまり1時間は、多くのデプロイメントでは必要以上に大きい値です。600秒つまり10分を最適化テストの出発点として使用することを検討してください。

6.5.10 Directory Serverにより使用されるシステム・リソースの制限

表6-2では、Directory Serverインスタンスによるシステム・リソースおよびネットワーク・リソースの使用方法をチューニングするために使用可能なパラメータについて説明します。

表6-2 システム・リソースに関するチューニング推奨事項

チューニング・パラメータ

説明

属性

dn: cn=configのnsslapd-listenhost

Directory ServerによりリスニングされるIPインタフェースのホスト名を設定します。この属性は複数の値を持つことができます。

この属性を設定するには、ldapmodifyコマンドを使用します。

デフォルト動作は、すべてのインタフェース上でリスニングすることです。このデフォルト動作は、冗長性のあるネットワーク・インタフェースを使用して可用性やスループットを高めるような、高ボリュームのデプロイメントに適しています。

マルチホーム・システム上にデプロイする場合や、IPv4またはIPv6の各プロトコルをそれぞれ個別のインタフェースを使用してサポートするようなシステム上でIPv4またはIPv6トラフィックのみをリスニングする場合に、この値の設定を検討してください。SSL使用時には、nsslapd-securelistenhostの設定を検討してください。

サーバー・プロパティ

file-descriptor-count

Directory Serverにより使用されるファイル記述子の最大数を設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

デフォルト値は、Directory Serverインスタンスが作成されるときに、システム上の1つのプロセスに許可されるファイル記述子の最大数です。その最大値は、システム上の1つのプロセスに許可されるファイル記述子の最大数に対応します。詳細は、オペレーティング・システムのドキュメントを参照してください。

Directory Serverでは、ファイル記述子を使用することで、クライアント接続を処理し、ファイルを内部的に維持します。使用可能なファイル記述子の数が十分でないために、Directory Serverで新しい接続のリスニングが時々停止していることがエラー・ログに示されている場合、この属性の値を増やすことで、Directory Serverで同時に処理できるクライアント接続の数が増加する可能性があります。

システム上で使用可能なファイル記述子の数を増やした場合には、この属性の値もそれに応じて設定してください。このプロパティの値は、システム上で使用可能なファイル記述子の最大数以下である必要があります。

属性

dn: cn=configのnsslapd-nagle

TCPパケットの送信をソケット・レベルで遅延させるかどうかを設定します。

この属性を設定するには、ldapmodifyコマンドを使用します。

ネットワークのトラフィックを減らす必要がある場合には、これをonに設定することを検討してください。

属性

dn: cn=configのnsslapd-reservedescriptors

Directory Serverにより、索引作成やレプリケーションなどの内部処理を管理するために維持されるファイル記述子の数を設定します。そのようなファイル記述子は、クライアント接続を処理するために使用できなくなります。

この属性を設定するには、ldapmodifyコマンドを使用します。

次のすべてに該当する場合には、この属性の値をデフォルトの64から増やすことを検討してください。

- Directory Serverで10個を超えるコンシューマにレプリケートするか、Directory Serverで30個を超える索引ファイルが維持されます。

- Directory Serverで多数のクライアント接続が処理されます。

- クライアント接続に関係しない操作用のファイル記述子がDirectory Serverで不足していることが、エラー・ログのメッセージで示されています。

確保済ファイル記述子の数が増加すると、クライアント接続の処理に使用可能なファイル記述子の数が減少することに注意してください。この属性の値を増やす場合には、システム上で使用可能なファイル記述子の数を増やし、file-descriptor-countの値を増やすことを検討してください。

確保するファイル記述子の数を初めて見積もる目的でこの属性を変更することにした場合、次の式に従ってnsslapd-reservedescriptorsの値を設定してみてください。

20 +
4 * (number of databases) +
(total number of indexes) +
(value of nsoperationconnectionslimit) *
(number of chaining backends) +
ReplDescriptors +
PTADescriptors +
SSLDescriptors

ここで、ReplDescriptorsは、レプリケーションが使用される場合は、サプライヤ・レプリカの数に8を加えたものになります。PTADescriptorsは、パススルー認証(PTA)プラグインが有効になっている場合は3、それ以外の場合は0になります。SSLDescriptorsは、SSLが使用される場合は5、それ以外の場合は0になります。

インスタンスが接尾辞ごとに2つ以上のデータベースを使用するように構成されていないかぎり、データベースの数はインスタンスの接尾辞の数と同じになります。見積りは、実験的なテストによって検証します。

属性

dn: cn=configのnsslapd-securelistenhost

Directory ServerでSSL接続をリスニングするIPインタフェースのホスト名を設定します。この属性は複数の値を持つことができます。

この属性を設定するには、ldapmodifyコマンドを使用します。

デフォルト動作は、すべてのインタフェース上でリスニングすることです。この属性はnsslapd-listenhostと同様に考えてください。

サーバー・プロパティ

max-thread-count

Directory Serverで使用されるスレッドの数を設定します。

このサーバー・プロパティを設定するには、dsconf set-server-propコマンドを使用します。

次のいずれかに該当する場合は、このプロパティの値を調整することを検討してください。

- クライアント・アプリケーションにより、更新や複雑な検索などの時間のかかる操作が同時に多数実行されます。

- Directory Serverによって、多数の同時クライアント接続がサポートされます。

マルチプロセッサ・システムでは、シングル・プロセッサ・システムよりも大きいスレッド・プールを維持できます。この属性の値を最適化する場合の最初の見積りとしては、プロセッサ数の2倍または20に同時更新数を加えたもののいずれかを使用します。

また、クライアント接続当たりの最大スレッド数max-threads-per-connection-countを調整することも検討してください。クライアント接続を処理するこれらのスレッドの最大数が、システム上で使用可能なファイル記述子の最大数を超えることはできません。場合によっては、この属性の値を増やすよりも減らす方が有効です。

見積りは、実験的なテストによって検証します。結果は、特定のデプロイメント状況だけでなく、基盤となるシステムによっても異なります。

6.6 Directory Server用のオペレーティング・システムのチューニング

デフォルトのシステム設定でディレクトリ・サービスのパフォーマンスが最高になるとはかぎりません。この項では、最高のパフォーマンスを実現するためのオペレーティング・システムのチューニング方法について説明します。

- オペレーティング・システムのバージョンとパッチのサポート

- 基本的なセキュリティ・チェック

- 正確なシステム・クロック時間

- システム・リブート時の再起動

- idsktuneコマンドによるシステム固有のチューニング

6.6.1 オペレーティング・システムのバージョンとパッチのサポート

サポートされるオペレーティング・システムの最新リストは、『Oracle Directory Server Enterprise Editionリリース・ノート』を参照してください。

システムの全体的なセキュリティを維持する必要があります。また、Directory Serverの正常な動作を保証する必要もあります。このため、推奨される最新のシステム・パッチ、サービス・パックまたはフィックスをインストールします。プラットフォームに適用される最新パッチの最新のリストは、『Oracle Directory Server Enterprise Editionリリース・ノート』を参照してください。

6.6.2 基本的なセキュリティ・チェック

こ項の推奨事項によって、すべてのリスクが排除されるわけではありません。推奨事項の目的は、一般的なセキュリティ上のリスクを制限するための簡潔なチェックリストを提供することです。

- ファイアウォールを使用してシステムを分離します。可能な場合、Directory Serverが稼働するシステムは、ネットワーク・ファイアウォールを使用して公的なインターネットから分離してください。

- デュアル・ブートを許可しません。本番用のDirectory Serverが稼働するシステムで、他のオペレーティング・システムを実行しないでください。ユーザーがアクセスを許可しないファイルへのアクセスが、他のシステムによって許可される可能性があります。

- 強力なパスワードを使用します。8文字以上の長さのrootパスワードを使用します。パスワードには、句読点などのアルファベット以外の文字も含めてください。
強力なパスワード・チェック・サーバー・プラグインを使用すると、脆弱なパスワードを拒否できます。dsconfサーバー・プロパティpwd-strong-check-enabledを使用して、プラグインを有効にできます。

より長いオペレーティング・システム・パスワードを使用する場合、システムによるパスワードの処理方法の構成が必要になることがあります。詳細は、オペレーティング・システムのドキュメントを参照してください。

- 安全なユーザーおよびグループIDをサーバーに使用します。セキュリティ上の理由により、スーパーユーザー権限を使用してDirectory Serverを実行しないでください。
たとえば、UNIXコマンドgroupaddおよびuseraddを使用すると、ログイン権限を持たないユーザーおよびグループを作成できます。次に、このユーザーとグループとしてサーバーを実行できます。

たとえば、serversという名前のグループを追加するには、次のようにします。

# groupadd servers

server1という名前のユーザーをグループserversのメンバーとして追加するには、次のコマンドを使用します。

# useradd -g servers -s /bin/false -c "server1"

ある特定のデプロイメントで、メッセージング・サーバーなどの他のサーバーとDirectory Serverファイルを共有する必要がある可能性があります。そのようなデプロイメントでは、同じユーザーおよびグループIDを使用してサーバーを実行することを検討してください。

- コア機能を使用します。デバッグを支援するために、このユーザーおよびグループIDで実行されているプロセスにコア・ダンプを許可できます。Solarisコマンドcoreadmなどのユーティリティを使用します。たとえば、Directory Serverでコア・ファイルを生成できるようにするには、setuidプロセスにその処理を許可した後、coreadmの構成を更新します。

# coreadm -e proc-setid
# coreadm -u

サーバーを起動するスクリプトを作成するとき、その起動スクリプトに次の行を追加できます。この行により、core.ns-slapd.pidという形式のコア・ファイルをDirectory Serverで生成できるようになります(ここで、pidはプロセスIDです)。

coreadm -p core.%f.%p $$

- 不要なサービスを無効にします。より少ないリスクで最高のパフォーマンスを実現するには、システムをDirectory Server専用にします。このガイドの別の箇所で説明しているように、同じマシン上でDirectory Service Control Centerを実行しないでください。別のサービス、特にネットワーク・サービスを実行すると、サーバーのパフォーマンスとスケーラビリティに悪影響が及びます。また、それにより、セキュリティ上のリスクも増大します。
できるだけ多くのネットワーク・サービスを無効にしてください。Directory Serverでは、ファイル共有やその他のサービスを必要としません。IPルーティング、メール、NetBIOS、NFS、RAS、WebパブリッシングおよびWindowsネットワーク・クライアントなどのサービスを無効にしてください。telnetおよびftpを無効にすることを検討してください。

telnetおよびftpは、多くのネットワーク・サービスと同様に、セキュリティ上のリスクとなります。これらのコマンドでは、ユーザーのパスワードがネットワーク経由でクリア・テキストとして送信されるため、これらの2つのサービスは特に危険です。telnetおよびftpが必要な場合は、回避策として、セキュア・シェル(ssh)やセキュアFTP (sftp)などのクライアントをかわりに使用してください。ネットワーク・サービスを無効にする方法の詳細は、オペレーティング・システムのドキュメントを参照してください。

Directory Serverインスタンスでネットワークに対してネーミング・サービスが提供されない場合、システムのネーミング・サービスを有効にすることを検討してください。その場合、Directory Serverでは、ACIを解決する場合などにそのネーミング・サービスを使用します。

6.6.3 正確なシステム・クロック時間

システム・クロックが他のシステムと適切に同期されていることを確認してください。クロックが適切に同期されていると、レプリケーションが容易になります。また、正確に同期されていることによって、ログ・ファイル内の日付やタイム・スタンプのシステム間での対応付けも容易になります。システム時刻を正しく設定するために、ネットワーク・タイム・プロトコル(NTP)クライアントを使用することを検討してください。

6.6.4 システム・リブート時の再起動

dsadmコマンドを使用して、システム・ブート時にサーバー・インスタンスを再起動できるようにすることができます。たとえば、Solaris 10およびWindowsシステムでは、dsadm enable-serviceコマンドを使用します。その他のシステムでは、dsadm autostartコマンドを使用します。システム・ブート時にサーバーが起動するようにする方法は、オペレーティング・システムのドキュメントを参照してください。

可能な場合は、dsadmコマンドを使用するかDSCCからDirectory Serverを停止します。システムの停止中にDirectory Serverが突然停止した場合、すべてのデータがディスクに正しく書き込まれたことは保証されません。したがって、Directory Serverでは、再起動するときに、データベースの完全性を検証する必要があります。このプロセスは時間がかかる場合があります。

さらに、ファイル・システムのロギング・オプションを使用することを検討します。一般的に、ファイル・システムのロギングによって、書込みパフォーマンスが向上すると同時に、ファイル・システム・チェックの実行に必要な時間が短縮されます。クラッシュ時にファイル・システムが正常にマウント解除されなかった場合、システムではファイル・システムをチェックする必要があります。また、RAIDをストレージとして使用することも検討します。

6.6.5 idsktuneコマンドによるシステム固有のチューニング

製品に付属のidsktuneユーティリティを使用すると、基本的なシステム構成の問題の診断に役立ちます。ユーティリティによって、高いパフォーマンスを示すディレクトリ・サービスをサポートするようにシステムをチューニングするための推奨事項が示されます。ユーティリティによって実際に推奨事項が実装されるわけではありません。適切な権限を持ったシステム管理者が、推奨事項を実装する必要があります。

ユーティリティをrootとして実行すると、idsktuneではシステムに関する情報を収集します。ユーティリティには、注意、警告およびエラーが推奨される対処法とともに表示されます。idsktuneコマンドでは、次のことがチェックされます。

- オペレーティング・システムとカーネルのバージョンが、このリリースでサポートされてること

- 使用可能なメモリーおよび使用可能なディスク領域が、通常用途の最小要件を満たしていること

- システム・リソースの限度が通常用途の最小要件を満たしていること

- 必須パッチがインストールされていること

ヒント:

Directory Serverソフトウェアを本番用のシステムにインストールする前に、少なくともすべてのERROR状態を解決してください。

個々のデプロイメント要件は、最小要件を上回る可能性があります。idsktuneユーティリティによって最小システム要件として指摘されたリソースよりも多くのリソースを提供できます。

特定の推奨事項を実装する前に、ローカル・ネットワークの状態やその他のアプリケーションについて検討します。ネットワーク設定のチューニングに関する追加のヒントは、オペレーティング・システムのドキュメントを参照してください。

6.6.5.1 ファイル記述子の設定

Directory Serverでは、同時クライアント接続を処理する場合にファイル記述子を使用します。そのため、サーバー・プロセスで使用可能なファイル記述子の最大数が小さい場合、同時接続数が制限される可能性があります。したがって、ファイル記述子の数に関する推奨事項は、Directory Serverで処理可能な同時接続数に関係します。

Solarisシステムの場合、使用可能なファイル記述子の数を構成するにはrlim_fd_maxパラメータを使用します。使用可能なファイル記述子の数を変更する手順の詳細は、オペレーティング・システムのドキュメントを参照してください。

6.6.5.2 伝送制御プロトコル(TCP)の設定

具体的なネットワーク設定はプラットフォームよって異なります。システムによっては、TCP設定を変更することでDirectory Serverのパフォーマンスを改善できます。

注意:

まずディレクトリ・サービスをデプロイし、次にそれらのパラメータのチューニングを必要に応じて検討します。

この項では、idsktuneによるTCP設定関連の推奨事項の背景にある根拠について説明した後、Solaris 10システム上でそれらの設定をチューニングする方法を示します。

6.6.5.2.1 非アクティブな接続

システムによっては、keepaliveパケットの送信間隔を構成できます。この設定によって、非アクティブであり切断されている可能性のあるTCP接続を、どのくらいの期間維持するかを決定できます。keepalive間隔の設定が大きすぎると、すでに切断されたクライアント接続を維持するために、システムで不要なリソースが使用される可能性があります。ほとんどのデプロイメントで、このパラメータの値を600秒に設定します。600,000ミリ秒つまり10分であるこの値によって、Directory Serverへの同時接続数を増やすことができます。

一方、keepalive間隔の設定値が小さすぎると、ネットワークの一時的な停止時にシステムによって接続が切断される可能性があります。

Solarisシステムでこの時間間隔を構成するには、tcp_keepalive_intervalパラメータを使用します。

6.6.5.2.2 発信接続

システムによっては、発信接続が確立されるまでのシステムの待機時間を構成できます。設定が高すぎると、すぐに応答しないレプリカなどのターゲット・サーバーへの発信接続を確立するときに、長い遅延が発生する可能性があります。高速で信頼性の高いネットワーク上のイントラネット・デプロイメントの場合、このパラメータの値を10秒に設定すると、パフォーマンスを改善できます。一方、接続が低速、信頼性が低いまたはWAN型であるネットワーク上では、そのような小さい値を使用しないでください。

Solarisシステムでこの時間間隔を構成するには、tcp_ip_abort_cintervalパラメータを使用します。

6.6.5.2.3 再送信タイムアウト

システムによっては、パケットの再送信間の初期時間間隔を構成できます。この設定は、確認応答のなかったパケットが再送信されるまでの待機時間に影響を与えます。設定が大きすぎると、失われたパケットをクライアントが待機し続ける可能性があります。高速で信頼性の高いネットワーク上のイントラネット・デプロイメントの場合、このパラメータの値を500ミリ秒に設定すると、パフォーマンスを改善できます。一方、ラウンドトリップ時間が250ミリ秒を超えるようなネットワークでは、そのような小さい値を使用しないでください。

Solarisシステムでこの時間間隔を構成するには、tcp_rexmit_interval_initialパラメータを使用します。

6.6.5.2.4 順序番号

システムによっては、システムによる初期順序番号の生成の処理方法を構成できます。エクストラネットおよびインターネット・デプロイメントでは、順序番号攻撃を回避するために、初期順序番号がRFC 1948に基づいて生成されるようにこのパラメータを設定してください。そのような環境では、ここに示した他のTCPチューニング設定は役立ちません。

Solarisシステムでこの動作を構成するには、tcp_strong_issパラメータを使用します。

6.6.5.2.5 Solaris 10システムでのTCP設定のチューニング

Solaris 10システムでTCP設定をチューニングする場合、最も単純な方法は、単純なSMFサービスを次のように作成することです。

- Directory Serverチューニング用のSMFプロファイルを作成します。

- 次のxmlファイルを環境に従って編集し、そのファイルを/var/svc/manifest/site/ndd-nettune.xmlとして保存します。

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/ service_bundle.dtd.1">
<!--
ident    "@(#)ndd-nettune.xml    1.0    04/09/21 SMI"
-->

<service_bundle type='manifest' name='SUNWcsr:ndd'>

<service
name='network/ndd-nettune'
type='service'
version='1'>

<create_default_instance enabled='true' />

<single_instance />

<dependency
name='fs-minimal'
type='service'
grouping='require_all'
restart_on='none'>
<service_fmri value='svc:/system/filesystem/minimal' />
</dependency>

<dependency
name='loopback-network'
grouping='require_any'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>

<dependency
name='physical-network'
grouping='optional_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/physical' />
</dependency>

<exec_method
type='method'
name='start'
exec='/lib/svc/method/ndd-nettune'
timeout_seconds='3' />
</exec_method>

<exec_method
type='method'
name='stop'
exec=':true'
timeout_seconds='3'>
</exec_method>

<property_group name='startd' type='framework'>
<propval name='duration' type='astring'  value='transient' />
</property_group>

<stability value='Unstable' />

<template>
<common_name>
<loctext xml:lang='C'>
ndd network tuning
</loctext>
</common_name>
<documentation>
<manpage title='ndd' section='1M'
manpath='/usr/share/man' />
</documentation>
</template>

</service>

</service_bundle>

- ndd-nettune.xmlの構成をインポートする前に、構文が正しいことを検証します。これを行うには、次のコマンドを実行します。

$ svccfg validate /var/svc/manifest/site/ndd-nettune.xml

- 次のコマンドを実行して構成をインポートします。

$ svccfg import /var/svc/manifest/site/ndd-nettune.xml

詳細は、svccfg(1M)のマニュアル・ページを参照してください。

- 次のシェル・スクリプトを/lib/svc/method/ndd-nettune内にコピーします。

#!/sbin/sh
#
# ident   "@(#)ndd-nettune.xml    1.0     01/08/06 SMI"

. /lib/svc/share/smf_include.sh
. /lib/svc/share/net_include.sh

# Make sure that the libraries essential to this stage of booting  can be found.
LD_LIBRARY_PATH=/lib; export LD_LIBRARY_PATH
echo "Performing Directory Server Tuning...">> /tmp/smf.out
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024
/usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 600000
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 10000
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000

# Reset the library path now that we are past the critical stage
unset LD_LIBRARY_PATH

- svcadmを実行してnettuneを有効にします(詳細は、svcadm(1M)のマニュアル・ページを参照してください)。

- svcs -xを実行します(詳細は、svcs(1)のマニュアル・ページを参照してください)。

6.7 Directory Serverの物理的機能

次に、Directory Serverのスケーラビリティを決定する物理的機能を示します。

- プロセス・サイズ。オペレーティング・システムによって異なりますが、32ビット・バージョンのDirectory Serverでは2GBから4GBのプロセス・サイズがサポートされます。64ビット・バージョンのDirectory Serverのプロセス・サイズは、マシン上で使用可能な物理メモリーの容量によって決定されます。128GBのプロセス・サイズによるテストが完了しています。

- LDAPエントリの数。1つのサーバー・インスタンス上で作成できるLDAPエントリの総数は2^32 -1、つまり4Gのエントリです。

- 各エントリのサイズ。LDAPサーバー内の1つのレコードのサイズは、DB自体に基づき、4GBとなります。また、エントリのサイズも、LDAPリクエストの最大サイズ(maxbersize)によって異なります。その最大値は2GBです。

- LDAP接続の数。LDAP接続の数は、プロセスでオープンできるファイル記述子の数によって異なります。一般的に、オープン接続の数が多すぎると、パフォーマンスが低下することに注意してください。

- LDAPサーバー(Berkery DB)のサイズ。LDAPサーバーのサイズは、使用するファイルシステムのサイズにより決定されます。

6.8 全体的なパフォーマンスを改善するためのその他のヒント

システムの全体的なパフォーマンスの改善に役立つヒントを次に示します。

- JDK 1.5ではなく、JDK 1.6を使用します。

$ export JAVA_HOME=JDK1.6-Installation-Directory

プロキシ・サーバー・インスタンスを再起動します。

- JRE 64ビットではなく、32ビットを使用します。

$ dpadm set-flags instance-path jvm-args="-Xmx250M -Xms250M -d32"

- ヒープ・サイズのほとんどを新規領域に割り当てます。たとえば、-XX:NewSize=500Mとします。

- jvm-argsでCMSガベージ・コレクションを使用します。たとえば、-XX:+UseConcMarkSweepGCとします。

- 不要な場合はアクセス・ログを無効にします。

$ dpconf set-access-log-prop default-log-level:none

6.9 キャッシュ設定のチューニング

この項では、データベースおよびエントリ・キャッシュ・サイズの設定に関する推奨事項を示します。インポート・キャッシュ・サイズはこの対象外となります。ここに示す推奨事項は、検索速度または変更速度のいずれかを最大化するためのものであり、その両方を一度に最大化するものではありません。

この項の内容は次のとおりです。

- 基本的なチューニング推奨事項

- 小規模、中規模および大規模なデータ・セット

- 最適な検索パフォーマンス(検索のみ)

- 最適な変更パフォーマンス(変更のみ)

6.9.1 基本的なチューニング推奨事項

ここでは、Directory Serverで実現される検索速度または変更速度を最大化するための基本的な推奨事項を示します。次の推奨事項に従って、キャッシュ・サイズを設定します。

6.9.1.1 検索速度の最大化(検索のみ)

ディレクトリ・データが使用可能な物理メモリー内に収まらないか、ちょうど収まって余分な領域がない場合は、db-cache-sizeをデフォルト値の32Mに設定して、オペレーティング・システムのファイル・システム・キャッシュをサーバーでできるだけ多く使用できるようにします。テストを実行し、スループットに基づいてサイズを正しく測定してください。

ディレクトリ・データが使用可能な物理メモリー内に収まり、物理メモリーに余分がある場合は、エントリ・キャッシュが一杯になるか、32ビット・システムの場合はエントリ・キャッシュが最大サイズに達するまで、エントリ・キャッシュにメモリーを割り当てます。次に、データベース・キャッシュが一杯になるか最大サイズに達するまで、データベース・キャッシュにメモリーを割り当てます。

キャッシュ・サイズの設定手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のメモリーの構成に関する説明を参照してください。

6.9.1.2 変更速度の最大化(変更のみ)

ディレクトリ・データが使用可能な物理メモリー内に収まらないか、ちょうど収まって余分な領域がない場合は、オペレーティング・システムのファイル・システム・キャッシュをできるだけ多くサーバーで使用できるようにします。使用可能なデータベース・キャッシュをいくらか残しておくことにより、各データベース・チェックポイント間で変更がキャッシュに入れられたままになります。

ディレクトリ・データが使用可能な物理メモリー内に収まり、物理メモリーに余分がある場合は、エントリ・キャッシュが一杯になるか、32ビット・システムの場合はエントリ・キャッシュが最大サイズに達するまで、エントリ・キャッシュにメモリーを割り当てます。次に、データベース・キャッシュが一杯になるか最大サイズに達するまで、データベース・キャッシュにメモリーを割り当てます。

キャッシュ・サイズの設定手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』のメモリーの構成に関する説明を参照してください。

6.9.2 小規模、中規模および大規模なデータ・セット

ワーキング・セットとは、サーバーがクライアント・アプリケーションに応答できるようにするために、実際にメモリーに取得されるデータのことです。データ・セットとは、クライアント・トラフィックが原因で使用されているディレクトリ内のエントリです。データ・セットは、ディレクトリ内の全エントリを含む場合や、ユーザーがアクティブであるタイム・ゾーンのユーザーに関連するエントリなど、より少数のエントリで構成される場合があります。

使用可能な物理メモリー内に収まるディレクトリ・データ・セットの量に基づいて、3つのデータ・セット・サイズを定義します。

小規模

データ・セットは完全に物理メモリー内に収まり、完全にロードされたデータベースおよびエントリ・キャッシュがあります。

中規模

データ・セットは物理メモリー内に収まり、余分の物理メモリーをエントリ・キャッシュに割り当てることができます。

大規模

データ・セットが小さく、使用可能な物理メモリー内に完全には収まりません。

理想的なのは、データ・セットが小規模であることです。データ・セットが小規模である場合、すべてのエントリがデータベース・キャッシュおよびエントリ・キャッシュの両方に収まるように、データベース・キャッシュ・サイズおよびエントリ・キャッシュ・サイズを設定してください。

次の項では、サーバーですべての検索またはすべての変更操作のいずれかが実行される、中規模および大規模データ・セットに関する推奨事項を示します。

6.9.3 最適な検索パフォーマンス(検索のみ)

図6-1に、仮想的なシステムにおける検索パフォーマンスを示します。予期されるとおり、ある特定のシステム構成について、Directory Serverの検索パフォーマンスが最高になるのは、データ・セット全体がメモリー内に収まる場合です。

図6-1 検索パフォーマンス

「図6-1 検索パフォーマンス」の説明

大規模データ・セットでは、データベース・キャッシュおよびエントリ・キャッシュがそれぞれ最小サイズに設定され、使用可能なメモリーが、オペレーティング・システムで、ファイル・システム・キャッシュの割当てに使用できるようになっている場合に、パフォーマンスが向上しています。示されているとおり、より多くのデータ・セットがファイル・システム・キャッシュ内に収まると、パフォーマンスが向上します。

中規模データ・セットでは、データ・セット全体がファイル・システム・キャッシュに保持され、使用可能な余分の物理メモリーがエントリ・キャッシュに使用される場合にパフォーマンスが向上しています。示されているとおり、より多くの中規模データ・セットがエントリ・キャッシュ内に収まると、パフォーマンスが向上します。

6.9.4 最適な変更パフォーマンス(変更のみ)

図6-2に、仮想的なシステムにおける変更パフォーマンスを示します。予期されるとおり、ある特定のシステム構成について、Directory Serverの変更パフォーマンスが最高になるのは、データ・セット全体がメモリー内に収まる場合です。

図6-2 変更パフォーマンス

「図6-2 変更パフォーマンス」の説明

大規模データ・セットでは、データベース・キャッシュおよびエントリ・キャッシュがそれぞれ最小サイズに設定され、使用可能なメモリーが、オペレーティング・システムで、ファイル・システム・キャッシュの割当てに使用できるようになっている場合に、パフォーマンスが向上しています。示されているとおり、より多くのデータ・セットがファイル・システム・キャッシュ内に収まると、パフォーマンスが向上します。

中規模データセットの場合、すべてのエントリがファイル・システム・キャッシュに収まった時点で変更パフォーマンスが最大になります。「基本的なチューニング推奨事項」で説明するとおり、使用可能なデータベース・キャッシュをいくらか残しておくことにより、各データベース・チェックポイント間で変更がキャッシュに入れられたままになります。

6.10 パフォーマンスのための索引のチューニング

索引を使用して検索の実行にかかる時間を短縮することにより、パフォーマンスを向上できます。ただし、索引にはそれに伴うコストもあります。エントリが更新された場合、そのエントリを参照している索引も更新する必要があります。索引付けされたエントリが増えるほど、索引の更新に必要なリソースが増え、索引がディスク領域およびメモリー領域を消費します。

索引を設計する場合は、検索の高速化によるメリットが索引に伴うコストを相殺するようにしてください。有用な索引を維持することはよい方法ですが、クライアントでほとんど検索されず、使用されない属性の索引を維持することは無駄です。

次の方法で検索のパフォーマンスを最適化できます。

- Directory Serverで、索引付けされていないエントリを検索できないようにします。

- 索引リストの長さを制限します。

- データベース・キャッシュのサイズが適切にチューニングされていることを確認します。

Directory Serverで索引付けされていないエントリを検索できないようにするには、接尾辞にrequire-index-enabled接尾辞プロパティを設定します。

特定の検索について索引キー当たりの値の数を制限するには、索引リストのしきい値を設定します。1つの検索キーに対するリスト内のエントリ数が索引リストのしきい値を超えた場合、索引を使用しない検索が実行されます。しきい値は、サーバー・インスタンス全体、接尾辞全体および個別の属性タイプに対して設定できます。等価、プレゼンスおよび部分文字列索引に対して個別のしきい値を設定することもできます。

索引リストのしきい値を変更する手順の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の索引リストのしきい値の変更に関する説明を参照してください。この手順により、all-ids-threshold構成プロパティが変更されます。

サーバー・インスタンスのall-ids-thresholdのグローバル値は、ディレクトリ内にあるエントリの合計数のおよそ5%である必要があります。たとえば、80000件以下のエントリを処理するDirectory Serverのインスタンスの場合、デフォルト値の4000が通常は適切です。非常に大規模なデプロイメントの場合にも、しきい値を50000より大きく設定しないでください。ただし、次の場合には、all-ids-thresholdを5%ガイドラインに従わない値に設定できます。

- ディレクトリの大幅な増大が見込まれ、しきい値を合計の5%より高く設定することが適切である場合。

- 多数の検索をサポートするコンシューマおよびほぼ書込みのみをサポートするマスターがあり、コンシューマとマスターに異なるしきい値を設定することが適切である場合。

- LDIFファイルから大きいディレクトリを初期化することを計画しており、初期化の直前にしきい値を変更することが適切である場合。

- ディレクトリに深い階層を持つディレクトリ情報ツリーがあり、1レベルまたはサブツリー検索を実行している場合。この場合、親および祖先索引のall-ids-thresholdを高く設定して、特定のブランチの下にある全エントリが索引付けされるようにできます。

索引を使用しない検索の実行数を制限する必要があります。Directory Server Resource Kitに付属のlogconvユーティリティを使用してアクセス・ログを確認し、索引を使用しない検索が頻繁に実行されている証拠を探します。詳細は、logconvのマニュアル・ページを参照してください。

6.11 基本的なDirectory Serverのサイズ設定の例: ディスクおよびメモリー要件

この項では、デプロイメント用のDirectory Serverのディスクおよびメモリー要件のサイズを設定する最初の手順を示す例について説明します。この例に使用されるシステムは、サイズ設定タスクを迅速に完了するために十分な処理能力およびメモリーを備えているシステムの中から、無作為に選択されたものです。必ずしも、本番用に推奨されるシステムを表しているわけではありません。ただし、これにより、本番システムでメモリーおよびディスク領域がどれだけ必要となるかについて、見通しを得ることができます。

6.11.1 システムの特性

次のシステム情報は、Solaris管理コンソール(smc)を使用して取得されたものです。

- 2つのAMD64 CPU (2.2GHz)

- Solaris 10オペレーティング・システム

- 4GBの物理メモリー

- 40GBのスワップ

- Directory Serverのインストール前に使用中だった物理メモリー: 700MB

- Directory Serverのインストール前の空き物理メモリー: 3400MB

- CPU使用率: 1%

- ローカル・ディスク: ロギング付きUFSとしてフォーマットされた1つのパーティション

この例では、システムはDirectory Server専用でした。他のユーザーはログインしておらず、デフォルトのシステム・プロセスのみが実行されていました。

6.11.2 Directory Serverインスタンスの準備

zipディストリビューションを展開して、ローカル・ディスク領域にDirectory Server Enterprise Editionソフトウェアをインストールします。

詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』のZipディストリビューションを使用したDirectory Server Enterprise Editionのインストールに関する説明を参照してください。

便宜上、環境変数を次のように設定します。

$ export PATH=/local/dsee7/bin:${PATH}
$ export DIRSERV_PORT=1389
$ export LDAP_ADMIN_PWF=~/.pwd

ソフトウェアのインストールおよび環境変数の設定が完了したら、LDAPおよびLDAPSそれぞれのデフォルト・ポートを使用するDirectory Serverインスタンスを作成します。

$ dsadm create -p 1389 -P 1636 /local/dsInst
Choose the Directory Manager password:
Confirm the Directory Manager password:
$ du -hs /local/dsInst
610K   /local/dsInst

接尾辞が作成されるまでは、Directory Serverインスタンスでは1MB未満のディスク領域を使用しています。

$ dsadm start /local/dsInst
Server started: pid=8046
$ dsconf create-suffix dc=example,dc=com
Certificate "CN=hostname, CN=1636, CN=Directory Server,
O=Sun Microsystems" presented by the server is not trusted.
Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more
details: Y
$ du -hs /local/dsInst
53M   /local/dsInst

この例では、明示的に示されているものを除き、Directory Serverのデフォルト構成に対する追加の変更は行いません。

6.11.3 10,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

makeldifコマンドとサンプル・ファイルを使用すると、サイズが1KBから1MBのサンプルLDIFファイルを作成できます。makeldifコマンドの使用方法を示す例は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサンプル・データのDirectory Serverインスタンスへのロードに関する説明を参照してください。

これらのファイル内のエントリは、実際のデプロイメントにおいて予期されるエントリより小さくなっています。

$ du -h /var/tmp/*
57M   /var/tmp/100k.ldif
5.7M   /var/tmp/10k.ldif
573M   /var/tmp/1M.ldif

これらのファイルのサンプル・エントリを、次のLDIFに示します。

dn: uid=Aartjan.Aalders,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: Aartjan
sn: Aalders
cn: Aartjan Aalders
initials: AA
uid: Aartjan.Aalders
mail: Aartjan.Aalders@example.com
userPassword: trj49xeq
telephoneNumber: 935-748-6699
homePhone: 347-586-0252
pager: 906-399-8417
mobile: 452-898-9034
employeeNumber: 1000004
street: 64197 Broadway Street
l: Lawton
st: IN
postalCode: 57924
postalAddress: Aartjan Aalders$64197 Broadway Street$Lawton, IN  57924
description: This is the description for Aartjan Aalders.

ディスク上で5.7MBを使用する10k.ldifの内容をインポートして、サイズ設定を開始します。

$ dsadm stop /local/dsInst
Server stopped
$ dsadm import -i /local/dsInst /var/tmp/10k.ldif dc=example,dc=com
…

デフォルトの索引作成では、10k.ldifの内容によって、インスタンス・ファイルのサイズが72MB - 53MB、つまり19MB増大します。

$ du -hs /local/dsInst
72M   /local/dsInst

追加で5つの属性の索引を作成すると、約7MBサイズが増大します。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ du -hs /local/dsInst
79M   /local/dsInst

デフォルトのキャッシュ設定を使用し、接尾辞からエントリ・キャッシュにまだ何もロードされていない状態でメモリー・サイズを確認すると、サーバー・プロセスによっておよそ170MBのメモリーが使用され、ヒープ・サイズは約56MBです。

$ dsadm start /local/dsInst
Server started: pid=8482
$ pmap -x 8482
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
0000000000437000      61348      55632      55380          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb     178444     172604      76532          -

次に、キャッシュをプライミングし、pmapコマンドの出力を再度確認すると、ヒープが約10MB増加しており、プロセスの合計サイズも同様です。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 8482
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65268      65024          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb     187692     182272      86224          -

この数値はデフォルトの索引作成の場合とほぼ同じです。

$ dsconf delete-index dc=example,dc=com employeeNumber street st \
postalCode description
$ dsconf reindex dc=example,dc=com
…
## example: Finished indexing.

Task completed (slapd exit code: 0).
$ dsadm stop /local/dsInst
Server stopped
$ dsadm start /local/dsInst
Server started: pid=8541
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 8541
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      70564      65248      65004          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb     187680     182240      86192          -

エントリが10,000件のみであるため、デフォルトのキャッシュ・サイズは変更しません。

$ dsconf get-server-prop | grep cache
db-cache-size                      :  32M
import-cache-size                  :  64M
$ dsconf get-suffix-prop dc=example,dc=com | grep entry-cache-size
entry-cache-size                   :  10M

デフォルトのエントリ・キャッシュはサイズが小さいため、エントリが10,000件のみである場合も、エントリ・キャッシュはプライミング後に確実に一杯になります。エントリが完全に収まるキャッシュのサイズを確認するには、大きいエントリ・キャッシュ・サイズを設定し、データを再度インポートして、キャッシュをプライミングします。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G
$ dsadm stop /local/dsInst
Server stopped
$ dsadm import -i /local/dsInst /var/tmp/10k.ldif dc=example,dc=com
…
$ dsadm start /local/dsInst
Server started: pid=8806
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 8806
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     116644     109996     109780          - rw---    [ heap ]

ここでは、10,000件のエントリによって、およそ55MB (110 - 55)のエントリ・キャッシュ・メモリーが使用されています。

6.11.4 100,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

エントリが100,000件になると、データベースおよびエントリ・キャッシュに収めるディレクトリ・データの量が増えます。まず、100,000件のエントリをインポートして、この量のディレクトリ・データに対して必要なディスク上のサイズを確認します。

$ dsadm import -i /local/dsInst /var/tmp/100k.ldif dc=example,dc=com
…
$ du -hs /local/dsInst
196M   /local/dsInst

データベースに格納されている、このサンプル接尾辞dc=example,dc=comのディレクトリ・データによって、現時点で約142MBが使用されています。

$ du -hs /local/dsInst/db/example/
142M   /local/dsInst/db/example

データベース・キャッシュのサイズを増やして、この内容を保持できます。ディレクトリ・データの量が時間の経過に伴って増大することが見込まれる場合、データベース・キャッシュを現在必要な量より大きく設定できます。エントリ・キャッシュ・サイズも必要な量より大きく設定できます。エントリ・キャッシュは、起動時に割り当てられるデータベース・キャッシュとは異なり、サーバーがクライアント・リクエストに応答するたびに増加します。

$ dsconf set-suffix-prop entry-cache-mode:manual
$ dsconf set-server-prop db-cache-size:200M
$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G

$ dsadm stop /local/dsInst
Server stopped
$ dsadm start /local/dsInst
Server started: pid=8640
$ pmap -x 8640
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      61348      55404      55148          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb     491984     485736     174620          -

これから、起動時のサーバー・インスタンスのヒープは比較的小さいが、データベース・キャッシュのメモリーは割当て済であることがわかります。プロセス・サイズはほぼ0.5GBです。

$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 8640
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     604064     603840          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb    1040880    1034428     723360          -

この時点で、ヒープ・サイズには、満たされたエントリ・キャッシュが反映されています。これは、100,000件の小規模なディレクトリ・エントリに対して約550MB増大し、そのLDIFによってディスク上の57MBが使用されています。

索引を5つ追加しても、プロセス・サイズはほぼ同じです。データベース・キャッシュ・サイズは変化していません。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
postalCode description
$ dsadm stop /local/dsInst
Server stopped
$ dsadm import -i /local/dsInst /var/tmp/100k.ldif dc=example,dc=com
…
$ dsadm start /local/dsInst
Server started: pid=8762
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 8762
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000     610212     603832     603612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb    1040876    1034192     723128          -

ただし、データベースは若干大きくなっています。追加の索引によって、データベースのサイズが142MBから163MBに増大しています。

$ du -hs /local/dsInst/db/example/
163M   /local/dsInst/db/example

6.11.5 1,000,000件のサンプル・ディレクトリ・エントリの接尾辞への移入

エントリが100,000件から1,000,000件になると、4GBの物理メモリーを持つシステム上には十分な領域を確保できず、エントリ・キャッシュにすべてのエントリを収めることはできなくなります。まず、データをインポートし、このデータによって使用されるディスク上のサイズを確認します。

$ dsadm import -i /local/dsInst /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/dsInst/db/example/
1.3G   /local/dsInst/db/example

インスタンスの存続期間中にディレクトリ・データ・サイズがおよそ25%増大することが予期されると想定して、データベース・キャッシュ・サイズを1700MBに設定します。

$ dsadm start /local/dsInst
Server started: pid=9060
$ dsconf set-server-prop db-cache-size:1700M
$ dsadm stop /local/dsInst
Server stopped
$ dsadm start /local/dsInst
Server started: pid=9118
$ pmap -x 9118
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000      65508      55700      55452          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb    1882448    1034180      76616          -

この大きさのデータベース・キャッシュと4GBのみの物理メモリーを使用する場合、接尾辞のエントリ・キャッシュには、エントリの一部分のみを収めることができます。ここで、エントリ・キャッシュ・サイズを1GBに設定し、キャッシュをプライミングして、プロセス・ヒープ・サイズの変化を確認します。

$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:1G
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \
objectclass=\*> /dev/null
Enter bind password:
$ pmap -x 9118
…
Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
…
0000000000437000    1016868    1009852    1009612          - rw---    [ heap ]
…
---------------- ---------- ---------- ---------- ----------
total Kb    2883268    2477064    1080076          -

合計プロセス・サイズは2.8GBを超えています。

$ prstat -p 9118
PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
9118 myuser   2816M 2374M sleep   59    0   0:03:26 0.5% ns-slapd/42

これまでのエントリ・キャッシュ・サイズに基づいて推定すると、十分な物理メモリーがある場合、エントリ・キャッシュのみで5.5から6GBが使用されることが予期できます。

索引を5つ追加してディレクトリ・データベースのサイズを確認すると、索引の追加によってデータベースのサイズが約200MB増大したことがわかります。

$ dsconf create-index dc=example,dc=com employeeNumber street st \
postalCode description
$ dsadm stop /local/dsInst
Server stopped
$ dsadm import -i /local/dsInst /var/tmp/1M.ldif dc=example,dc=com
…
$ du -hs /local/dsInst/db/example
1.5G   /local/dsInst/db/example

6.11.6 結果のサマリー

表6-3に、この例での結果を記録します。これには、サーバー・プロセス・サイズおよびデフォルトのデータベース・キャッシュ・ファイル・サイズはいずれも含まれていません。

注意:

実際のデプロイメントにおける実験的なテストの結果は、通常、ここに示すものとは大きく異なります。

表6-3 サイズ設定サマリー

エントリ数

LDIFファイル・サイズ

デフォルト索引を持つディスク

索引が5つ追加されたディスク

データベース・キャッシュ

エントリ・キャッシュ

0脚注 1

該当なし

該当なし

該当なし

該当なし

該当なし

10,000

8MB

19MB

26MB

32MB

55MB

100,000

83MB

142MB

163MB

200MB

550MB

1,000,000

800MB

1300MB

1500MB

1700MB (デフォルトの索引作成)

該当なし

脚注 1 接尾辞は作成されていますが、空です。

実際のデプロイメントでは、エントリおよび索引の数が大幅に増加する可能性があります。ハードウェアを注文する前に、実験的なテストとチューニングを行ってください。

7 セキュリティ要件の特定

Directory Server Enterprise Editionでデータを保護する方法は、設計の他のすべての領域に影響します。この章では、セキュリティ要件の分析方法およびその要件を満たすディレクトリ・サービスの設計方法について説明します。

この章の内容は、次のとおりです。

- セキュリティの脅威

- セキュリティ方式の概要

- 認証方式の決定

- プロキシ認可

- パスワード・ポリシーの設計

- Windowsとのパスワードの同期

- 暗号化方式の決定

- ACIによるアクセス制御の設計

- Directory Proxy Serverによるアクセス制御の設計

- エントリの安全なグループ化

- ファイアウォールの使用

- root以外として実行

- その他のセキュリティ・リソース

7.1 セキュリティの脅威

ディレクトリのセキュリティに対する最も一般的な脅威には、次のものがあります。

- 傍受。情報は元の状態のままですが、そのプライバシが損なわれます。たとえば、他人に、クレジット・カード番号を知られたり、機密性の高い会話を記録されたり、機密情報を傍受される可能性があります。

- 未許可アクセス。この脅威には、データのフェッチ操作による、データへの未許可アクセスが関与します。また、未許可のユーザーが、他のユーザーのアクセスを監視することにより、再使用可能なクライアント認証情報にアクセスする可能性もあります。Directory Server Enterprise Editionの認証方式、パスワード・ポリシーおよびアクセス制御メカニズムを使用することで、効果的に未許可アクセスを防止できます。

- 改ざん。転送中の情報が変更または置換されて受信者に送信されます。たとえば、他人が商品の注文を変更したり、履歴書を変更する可能性があります。
この脅威には、データまたは構成情報の未許可の変更が関与します。ディレクトリで改ざんを検出できない場合、攻撃者がサーバーに対するクライアントのリクエストを変更する可能性があります。また、攻撃者がリクエストを取り消したり、クライアントに対するサーバーのレスポンスを変更する可能性もあります。Secure Socket Layer (SSL)プロトコルおよび類似のテクノロジを使用し、接続の両側で情報に署名することによって、この問題を解決できます。

- 偽装。目的の受信者を装ったユーザーに情報が渡されます。
偽装には、スプーフィングと虚偽表示の2つの形態があります。

- スプーフィング。人またはコンピュータが、他の人やコンピュータになりすます行為です。たとえば、ある人がjdoe@example.comというメール・アドレスを持っているふりをしたり、あるコンピュータが、実際とは異なる、www.example.comという名前のサイトであると識別されるようにする可能性があります。

- 虚偽表示。人または組織が自分自身について虚偽の表示をする行為です。たとえば、サイトwww.example.comが、家具販売店であるふりをしているが、実際にはクレジット・カードによる支払いを受けても決して商品を発送しないサイトである場合があります。

- サービス拒否。攻撃者がシステム・リソースを使用することで、正規ユーザーがこれらのリソースを使用できないようにします。
サービス拒否攻撃における攻撃者の目的は、ディレクトリによるクライアントへのサービスの提供を妨害することです。Directory Server Enterprise Editionでは、特定のバインドDNに割り当てられるリソースに制限を設定することで、サービス拒否攻撃を防止します。

7.2 セキュリティ方式の概要

セキュリティ・ポリシーは、未許可のユーザーによる機密情報の変更や取得を防止できるとともに、管理が容易である必要があります。

Directory Server Enterprise Editionでは、次のセキュリティ方式を使用できます。

- 認証。一方が他方のアイデンティティを検証する方法を提供します。たとえば、LDAPバインド操作中に、クライアントからDirectory Serverにパスワードが提示されます。認証プロセスの一部であるパスワード・ポリシーでは、有効期限、長さ、構文など、パスワードが有効であるとみなされるために満たす必要のある基準を定義します。アカウントの非アクティブ化では、ユーザー・アカウント、アカウントのグループまたはドメイン全体を無効にして、すべての認証試行が自動的に拒否されるようにします。

- 暗号化。情報のプライバシを保護します。データが暗号化されるとき、受信者のみがデコードできるような方法でスクランブルがかけられます。Secure Sockets Layer (SSL)では、転送中の情報を暗号化することによってデータの整合性を維持します。暗号化およびメッセージ・ダイジェストが送信される情報に適用されている場合、受信者は、その情報が転送中に改ざんされていないことを確認できます。属性の暗号化では、格納されている情報を暗号化することで、データの整合性を維持します。

- アクセス制御。異なるディレクトリ・ユーザーに付与されるアクセス権を調整し、必要な資格証明またはバインド属性を指定する方法を提供します。

- 監査。ディレクトリのセキュリティが損なわれているかどうかを確認できます。たとえば、ディレクトリで維持されているログ・ファイルを監査できます。

これらのセキュリティ・ツールは、ユーザーのセキュリティ設計で組み合せて使用できます。また、セキュリティ設計をサポートするために、レプリケーションやデータ分散などの、ディレクトリのその他の機能を使用することもできます。

7.3 認証方式の決定

Directory Server Enterprise Editionでは、次の認証メカニズムがサポートされます。

- 匿名アクセス

- 簡易パスワード認証

- セキュア接続での簡易パスワード認証

- 証明書ベースのクライアント認証

- SASLベースのクライアント認証

ユーザーが人であるかLDAP対応アプリケーションであるかに関係なく、すべてのユーザーに同じ認証メカニズムが適用されます。

この項では、前述の認証メカニズム以外に、認証に関する次の情報についても説明します。

- アカウントの非アクティブ化による認証の防止

- グローバル・アカウント・ロックアウトを使用した認証の防止

- 外部認証のマッピングおよびサービス

7.3.1 匿名アクセス

匿名アクセスは、最も単純な形態のディレクトリ・アクセスです。匿名アクセスによって、ユーザーが認証済であるかどうかに関係なく、すべてのディレクトリ・ユーザーがデータを使用できるようになります。

匿名アクセスでは、誰が検索を実行しているか、またはどのような種類の検索が実行されているかは追跡できず、誰かが検索を実行していることのみを追跡できます。匿名アクセスを許可すると、ディレクトリに接続する誰もがデータにアクセスできます。データへの匿名アクセスを許可し、そのデータからユーザーまたはグループをブロックしようとした場合、そのユーザーは匿名でディレクトリにバインドしてデータにアクセスできます。

匿名アクセスの権限を制限できます。通常、ディレクトリ管理者は、読取り、検索および比較権限のみを匿名アクセスに許可します。また、名前、電話番号および電子メール・アドレスなどの一般情報を含む属性のサブセットにアクセスを限定することもできます。政府指定の識別番号、自宅の電話番号や住所、給与情報など、機密データへの匿名アクセスを許可しないでください。

ルートDSEへの匿名アクセス(ベースDN "")は必須です。アプリケーションでは、ルートDSEへのアクセスを使用することで、サーバーの機能、サポートされているセキュリティ・メカニズムおよびサポートされている接尾辞を確認できます。

7.3.2 簡易パスワード認証

匿名アクセスが設定されていない場合、クライアントでディレクトリの内容にアクセスするには、Directory Serverへの認証を行う必要があります。簡易パスワード認証では、クライアントは再使用可能な単純なパスワードを提供して、サーバーへの認証を行います。

クライアントでは、識別名と資格証明を提供するバインド操作を使用して、Directory Serverへの認証を行います。サーバーでは、そのクライアントDNに対応するエントリを特定した後で、そのクライアントのパスワードがエントリに格納された値に一致するかどうかをチェックします。パスワードが一致する場合、サーバーによりそのクライアントが認証されます。パスワードが一致しない場合、認証操作は失敗し、クライアントにエラー・メッセージが返されます。

注意:

簡易パスワード認証のデメリットは、パスワードがクリア・テキストとして送信されるため、セキュリティが損なわれる場合があることです。悪意のあるユーザーが盗聴している場合、そのユーザーは許可されたユーザーを偽装できます。

簡易パスワード認証を使用することで、ユーザーの認証が容易になります。ただし、簡易パスワード認証を使用するのは、組織のイントラネットに限定する必要があります。この種類の認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティは提供されません。

7.3.3 セキュア接続での簡易パスワード認証

セキュア接続では、暗号化によって第三者がデータを読むことができないようにすると同時に、Directory Serverとクライアント間のネットワークを経由してデータを送信します。クライアントでは、次のいずれかの方法でセキュア接続を確立できます。

- Secure Socket Layer (SSL)を使用して保護ポートにバインドします。

- 保護されていないポートに匿名アクセスでバインドし、Start TLS制御を送信してトランスポート層セキュリティ(TLS)の使用を開始します。

いずれの場合も、サーバーにはセキュリティ証明書が必要であり、この証明書を信頼するようにクライアントを構成する必要があります。サーバーでは、証明書をクライアントに送信することで、公開鍵暗号化を使用してサーバー認証を実行します。その結果、目的のサーバーに接続していること、およびサーバーが改ざんされていないことが、クライアントによって認識されます。

次に、プライバシを保護するために、クライアントとサーバーでは、接続を介して転送されるすべてのデータを暗号化します。クライアントでは、ユーザーを認証するために、暗号化された接続でバインドDNとパスワードを送信します。それ以降のすべての操作は、そのユーザーのアイデンティティを使用して実行されます。また、バインドDNが他のユーザー・アイデンティティに対するプロキシ権限を持っている場合には、プロキシ・アイデンティティを使用して操作が実行される可能性もあります。いずれの場合も、操作の結果は暗号化されてクライアントに返されます。

7.3.4 証明書ベースのクライアント認証

SSLまたはTLS経由で暗号化接続を確立する場合、クライアント認証を要求するようにサーバーを構成することもできます。クライアントからは、ユーザーのアイデンティティを確認するために、サーバーに証明書を送信する必要があります。バインドDNの決定には、ユーザーのDNではなく、証明書が使用されます。クライアント認証は、ユーザーの偽装に対する保護で、最も安全なタイプの接続です。

証明書ベースのクライアント認証は、SSLおよびTLS層でのみ動作します。証明書ベースの認証IDをLDAPで使用するには、SSL接続の確立後にSASL EXTERNAL認証を使用する必要があります。

証明書ベースのクライアント認証を構成するには、dsconf get-server-propコマンドを使用します。詳細は、dsconfを参照してください。

7.3.5 SASLベースのクライアント認証

SSLまたはTLS接続時のクライアント認証では、汎用セキュリティ・インタフェースのSimple Authentication and Security Layer (SASL)を使用してクライアントのアイデンティティを確立することもできます。Directory Server Enterprise Editionでは、SASLを使用して次のメカニズムをサポートします。

- DIGEST-MD5。このメカニズムでは、クライアントから送信されたハッシュ値とユーザー・パスワードのハッシュを比較することによって、クライアントを認証します。ただし、このメカニズムではユーザー・パスワードを読み取る必要があるため、DIGEST-MD5による認証を希望するすべてのユーザーは、ディレクトリ内に{CLEAR}パスワードを持つ必要があります。

- GSSAPI。General Security Services API (GSSAPI)は、Solarisオペレーティング・システムでのみ使用できます。これにより、Directory ServerではKerberos V5セキュリティ・システムと対話してユーザーを特定できます。クライアント・アプリケーションではKerberosシステムに資格証明を提示する必要があり、Kerberosシステムでは、ユーザーのアイデンティティを検証してDirectory Serverに返します。

- EXTERNAL。このメカニズムでは、SSLやTLSなどの外部セキュリティ・レイヤーによって指定された資格証明に基づいて、LDAPのユーザーを認証します。

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントでのSASL DIGEST-MD5の使用に関する説明および『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントでのKerberos SASL GSSAPIに関する説明を参照してください。

7.3.6 アカウントの非アクティブ化による認証の防止

あるユーザー・アカウントまたは一連のアカウントを非アクティブにすることで、認証を一時的に防止できます。アカウントを非アクティブにされたユーザーは、Directory Serverにバインドできず、認証処理が失敗します。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のアカウントの手動ロックに関する説明を参照してください。

7.3.7 グローバル・アカウント・ロックアウトを使用した認証の防止

このバージョンのDirectory Serverでは、パスワードによる認証失敗が監視およびレプリケートされます。これにより、無効なパスワードによる認証の試行がある指定された回数だけ行われた後、速やかにグローバル・アカウント・ロックアウトできます。グローバル・アカウント・ロックアウトは、次のすべての場合にサポートされます。

- クライアント・アプリケーションがトポロジ内の単一のサーバーにのみバインドする場合

- 読取り専用のコンシューマがトポロジ内に含まれていない場合

- Directory Proxy Serverを使用してすべてのバインド・トラフィックが制御される場合

すべてのバインド試行が同一のサーバーに向けられず、ロックアウト・データがレプリケートされるよりも速く、クライアント・アプリケーションにより複数のサーバー上でバインド試行が実行されるような状況を想像してください。最悪の場合、クライアントによりバインドが試行されたサーバーごとに、指定された回数の試行をクライアントに許可することになります。人間のユーザーの入力によってクライアント・アプリケーションが駆動される場合、通常、このような状況は発生しません。ただし、トポロジを攻撃するために構築された自動化クライアントでは、このデプロイメントの選択を悪用できます。

優先順位付きレプリケーションを使用すると、侵入者が検出されたときに、非同期レプリケーションの遅れによる影響を最小化できます。ただし、バインド試行が指定された回数だけ失敗した直後にアカウント・ロックアウトを実行する必要がある場合もあります。このような状況では、ある特定のエントリ上でのすべてのバインド試行を、Directory Proxy Serverを使用して同一のマスター・レプリカにルーティングする必要があります。これを行うためのDirectory Proxy Serverの構成方法は、Oracle Directory Server Enterprise Editionリファレンスのグローバル・アカウント・ロックアウトの操作アフィニティ・アルゴリズムに関する説明を参照してください。

レプリケーション・トポロジ内で厳密にローカルなロックアウト・ポリシーを維持するには、5.2のパスワード・ポリシーとの互換性を維持する必要があります。その状況では、有効なポリシーをデフォルトのパスワード・ポリシーにすることはできません。また、読取り専用のコンシューマにバインドを制限することによっても、ローカル・ロックアウトを実現できます。

グローバル・アカウント・ロックアウトの動作方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスのグローバル・アカウント・ロックアウトに関する説明を参照してください。

7.3.8 外部認証のマッピングおよびサービス

Directory Serverでは、ネットワーク・ユーザー・アカウントをDirectory Serverユーザー・アカウントに関連付けるユーザー・アカウント・ホスト・マッピングを使用できます。この機能によって、両方のユーザー・アカウントの管理が簡略化されます。ホスト・マッピングは、外部で認証されたユーザーの場合に必要です。

7.4 プロキシ認可

プロキシ認可は、特殊な形態のアクセス制御です。プロキシ認可またはプロキシ認証においては、アプリケーションが、特定のユーザー名/パスワードの組合せを使用してサーバーへのアクセスを取得することを強制されます。

プロキシ認可では、管理者は、ある一般ユーザーのアイデンティティを引き受けることでDirectory Serverへのアクセスを要求できます。管理者は、自分自身の資格証明を使用してディレクトリにバインドし、その一般ユーザーの権限を付与されます。この引き受けるアイデンティティをプロキシ・ユーザーと呼びます。そのユーザーのDNはプロキシDNと呼びます。プロキシ・ユーザーは一般ユーザーとして評価されます。プロキシ・ユーザーのエントリがロックまたは非アクティブ化されているか、そのパスワードの有効期限が切れている場合、アクセスが拒否されます。

プロキシ・メカニズムの利点は、Directory Serverにアクセスする複数のユーザーに対して、LDAPアプリケーションで単一のバインドを使用してサービスを提供できることにあります。各ユーザーがバインドおよび認証する必要があるのではなく、クライアント・アプリケーションでDirectory Serverにバインドし、プロキシの権限を使用します。

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。

7.5 パスワード・ポリシーの設計

パスワード・ポリシーは、システム内でのパスワードの管理方法を制御するルールのセットです。Directory Serverでは、デフォルトのパスワード・ポリシー以外に、複数のパスワード・ポリシーがサポートされています。

パスワード・ポリシーのいくつかの要素は構成可能であるため、組織のセキュリティ要件に合ったポリシーを設計できます。パスワード・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第7章「Directory Serverのパスワード・ポリシー」を参照してください。パスワード・ポリシーの構成に使用可能な個々の属性は、pwpolicyのマニュアル・ページを参照してください。

この項は次のトピックに分割されています。

- パスワード・ポリシーのオプション

- レプリケーション環境でのパスワード・ポリシー

- パスワード・ポリシーの移行

7.5.1 パスワード・ポリシーのオプション

次のパスワード・ポリシーのオプションがあります。

- デフォルトのパスワード・ポリシーが適用されます。このデフォルト・ポリシーのパラメータは変更可能です。

- 別の特殊なパスワード・ポリシーを特定のユーザーに適用できます。

- CoSおよびロール機能を使用することで、別の特殊なパスワード・ポリシーを一連のユーザーに適用できます。パスワード・ポリシーは、静的なグループには適用できません。

7.5.2 レプリケーション環境でのパスワード・ポリシー

デフォルト・パスワード・ポリシーの構成情報はレプリケートされません。かわりに、サーバー・インスタンスの構成の一部となります。デフォルト・パスワード・ポリシーを変更する場合は、トポロジ内のすべてのサーバーに同じ変更を加える必要があります。レプリケートされるパスワード・ポリシーが必要な場合は、レプリケートされるディレクトリ・ツリー内に、特殊なパスワード・ポリシーを定義する必要があります。

ユーザー・エントリに格納されているパスワード情報のすべてがレプリケートされます。この情報には、現在のパスワード、パスワード履歴、パスワードの有効期限などが含まれます。

レプリケーション環境では、パスワード・ポリシーによる次の影響を考慮してください。

- パスワードの期限切れが近づいたユーザーは、パスワードを変更するまで、バインドするすべてのレプリカから警告を受信します。

- ユーザーがパスワードを変更した場合、その新しいパスワードがすべてのレプリカ上で更新されるまでに、しばらく時間がかかる可能性があります。ユーザーが、パスワードを変更した直後に、新しいパスワードを使用してコンシューマ・レプリカの1つにバインドしなおす状況になることがあります。この場合、そのレプリカが更新済のパスワードを受信するまで、バインドが失敗する可能性があります。この状況を緩和するには、優先順位付きレプリケーションを使用してパスワード変更が最初にレプリケートされるように強制します。

7.5.3 パスワード・ポリシーの移行

Directory Server Enterprise Editionのパスワード・ポリシーの構成設定は、5.2バージョンのDirectory Serverで提供されていたパスワード・ポリシーの構成設定とは異なります。異なるバージョンのDirectory Serverが稼働するサーバーがトポロジ内に含まれている場合は、パスワード・ポリシーの設定の移行方法の詳細について、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』のパスワード・ポリシーに関する説明を参照してください。

7.6 Windowsとのパスワードの同期

Identity Synchronization for Windowsでは、Directory ServerとWindowsとの間で、パスワードを含むユーザー・アカウント情報を同期させます。Windows Active DirectoryとWindows NTの両方がサポートされます。Identity Synchronization for Windowsは、小規模、中規模および大規模企業向けに、スケーラビリティの高いセキュリティ機能の豊富なパスワード同期ソリューションを構築する場合に役立ちます。

このソリューションでは次のものが提供されます。

- Active Directory、Windows NTとDirectory Serverの間における、アカウントの作成、変更、非アクティブ化および削除の同期

- ネイティブ・パスワード変更を同期させるための、異なる固有ディレクトリ・ソースとの統合

デプロイメントでのIdentity Synchronization for Windowsの使用方法の詳細は、Identity Synchronization for Windowsのデプロイメント・プランニング・ガイドを参照してください。

7.7 暗号化方式の決定

暗号化は、転送中のデータや格納されたデータを保護する場合に役立ちます。この項では、次のデータ暗号化方式について説明します。

- SSLによる接続の保護

- 保存された属性の暗号化

7.7.1 SSLによる接続の保護

セキュリティ設計には、ユーザーを特定するための認証スキームや、情報を保護するためのアクセス制御スキーム以外の要素も含まれます。サーバーとクライアント・アプリケーションとの間でネットワーク経由で送信される情報の整合性も保護する必要があります。

ネットワーク上で安全な通信を可能にするために、Secure Sockets Layer (SSL)上でLDAPプロトコルとDSMLプロトコルの両方を使用できます。SSLが構成されてアクティブ化されると、クライアントでは、SSL接続の確立後にすべての通信が暗号化される、専用の保護ポートに接続します。Directory ServerとDirectory Proxy Serverでは、Start Transport Layer Security (Start TLS)制御もサポートされています。クライアントではStart TLSを使用して、標準のLDAPポート経由での暗号化接続を開始できます。

Directory ServerのSSLおよびTLSの概要は、Oracle Directory Server Enterprise Editionリファレンスの第5章「Directory Serverのセキュリティ」を参照してください。

7.7.2 保存された属性の暗号化

属性の暗号化は、格納されたデータの保護に関係します。この項では、属性の暗号化機能について説明し、次のトピックを取り上げます。

- 属性の暗号化とは

- 属性の暗号化の実装

- 属性の暗号化とパフォーマンス

7.7.2.1 属性の暗号化とは

Directory Server Enterprise Editionには、パスワード認証、証明書ベースの認証、SSLおよびプロキシ承認など、アクセス・レベルでデータを保護する様々な機能が備えられています。ただし、データベース・ファイル、バックアップ・ファイルおよびLDIFファイルに格納されたデータも保護する必要があります。属性の暗号化機能を使用することで、格納されている機密データにユーザーがアクセスできないよう防止できます。

属性の暗号化を使用すると、特定の属性を暗号化された形式で格納できます。属性の暗号化はデータベース・レベルで構成されます。したがって、ある属性を暗号化すると、その属性がデータベース内のすべてのエントリで暗号化されます。属性の暗号化は、エントリ・レベルではなく属性レベルで行われるため、エントリ全体を暗号化する唯一の方法は、すべての属性を暗号化することです。

属性の暗号化を使用すると、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、機密データが格納またはエクスポートされる場合にのみ、それらのデータを保護することです。したがって、この暗号化は常に可逆です。検索リクエストの結果として返されるときには、暗号化された属性が復号化されます。

次の図は、データベースに追加されるユーザー・エントリを示しており、ここに示す属性の暗号化は、salary属性を暗号化するように構成されています。

図7-1 属性の暗号化のロジック

「図7-1 属性の暗号化のロジック」の説明

7.7.2.2 属性の暗号化の実装

属性の暗号化機能では、広範な暗号化アルゴリズムがサポートされています。異なるプラットフォーム間での移植性が保証されています。属性の暗号化では、追加のセキュリティ手段として、サーバーのSSL証明書の非公開鍵を使用して、それ自体の鍵を生成します。その後、この鍵は、暗号化および復号化処理を実行するために使用されます。属性を暗号化できるためには、サーバーがSSL上で稼働している必要があります。SSL証明書とその非公開鍵はデータベース内に安全に格納され、パスワードで保護されます。この鍵データベースのパスワードはサーバーへの認証時に必要です。サーバーでは、この鍵データベースのパスワードにアクセスできるすべてのユーザーが、復号化されたデータのエクスポートを承認されているとみなします。

属性の暗号化によって保護されるのは、保存された属性のみであることに注意してください。これらの属性をレプリケートする場合には、転送中の属性を保護するように、SSL上でレプリケーションを構成する必要があります。

属性の暗号化を使用する場合、バイナリ・コピー機能を使用してあるサーバーから別のサーバーを初期化することはできません。

7.7.2.3 属性の暗号化とパフォーマンス

属性を暗号化することでデータのセキュリティが向上しますが、この機能はパフォーマンスにも影響を及ぼします。属性の暗号化は、機密性の特に高い属性を暗号化するためにのみ使用してください。

機密データには、索引ファイル経由で直接アクセスできます。したがって、暗号化する属性に対応する索引キーを暗号化することで、それらの属性が完全に保護されるようにする必要があります。索引キーを暗号化することによる追加コストはありませんが、索引を作成することがすでにパフォーマンスに影響を及ぼしています。したがって、データベースに初めてデータをインポートまたは追加する前に、属性の暗号化を構成してください。こうすることで、暗号化された属性には最初から索引が付けられます。

7.8 ACIによるアクセス制御の設計

アクセス制御では、特定の情報へのアクセス権を一部のクライアントに付与し、その他のクライアントには付与しないように指定できます。アクセス制御は、1つ以上のアクセス制御リスト(ACL)を使用して実装します。ACLは、指定されたエントリとその属性に対する権限を許可または拒否する一連のアクセス制御命令(ACI)で構成されます。権限には、読取り、書込み、検索、プロキシ、追加、削除、比較、インポートおよびエクスポートを行う権限が含まれます。

ACLを使用すると、次の項目に対する権限を設定できます。

- ディレクトリ全体

- ディレクトリの特定のサブツリー

- ディレクトリ内の特定のエントリ

- エントリの属性の特定のセット

- 特定のLDAP検索フィルタに一致するすべてのエントリ

また、特定のユーザー、グループに属するすべてのユーザーまたはディレクトリのすべてのユーザーに対する権限を設定できます。さらに、IPアドレスやDNS名など、ネットワークの場所に対してアクセス権を定義することもできます。

この項では、Directory Serverのアクセス制御メカニズムの概要を示します。アクセス制御およびACIの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。アクセス制御メカニズムのアーキテクチャの詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverによるアクセス制御の実施方法に関する説明を参照してください。

7.8.1 デフォルトACI

デフォルトの動作では、Directory Serverは、アクセスを許可する特定のACIがないかぎりアクセスを拒否します。したがって、ACIが定義されていない場合、サーバーへのすべてのアクセスが拒否されます。

Directory Serverをインストールしたり新しい接尾辞を追加すると、ルートDSE内にいくつかのデフォルトACIが自動的に定義されます。これらのACIは、セキュリティ要件に合うように変更できます。

デフォルトACIおよびそれらの変更方法の詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverによるアクセス制御の実施方法に関する説明を参照してください。

7.8.2 ACIの対象範囲

Directory Server 6.x以上には、ACIの対象範囲に対する主な変更が2つ含まれています。

- ACIの対象範囲を指定する機能。Directory Server 5.2では、ACIの対象範囲を指定できませんでした。ACIは自動的に、そのACIの格納先となるエントリとそのすべてのサブツリーに対して適用されていました。このため、場合によっては拒否ACIを使用する必要がありました。拒否ACIと許可ACIが単一のエントリに適用される場合は、特に、拒否ACIの管理が困難になる可能性があります。
Directory Server 6.x以上では、ACIの対象範囲を指定できます。つまり、許可ACIを使用してアクセスを制御できます。拒否ベースのアクセス制御の使用が避けられない場合や、そのようなアクセス制御を使用した方が構成が容易になる場合もありますが、拒否ACIを使用することは、基本的にはお薦めしません。ACIの対象範囲を指定する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。

- ルートACIがルート・エントリおよびそのサブツリー全体に適用されるようになりました。Directory Server 5.2では、ルートDSEに格納されたACIはルート・エントリにのみ適用され、その子には適用されませんでした。その他のエントリ内に配置されたACIは、そのACIの格納先となるエントリとそのすべてのサブツリーに対して適用されていました。Directory Server Enterprise Editionでは、ルート・エントリ内に配置されたACIが、他の任意の場所に配置されたACIと同様に扱われます。
新しいルートACIには、明白なセキュリティ上の利点が1つあります。管理者は、特定の操作を実行するときにディレクトリ・マネージャとしてバインドする必要がなくなりました。SSLなどの強力な認証によるバインドを管理者に強制できるようになりました。今後、ルート・エントリにのみ適用することを目的としたACIを構成するには、そのACIの対象範囲を具体的にbaseに設定する必要があります。

ACIの対象範囲の変更は移行に影響を与えます。5.2バージョンのDirectory ServerからDirectory Server 7.0に移行する場合は、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』のACIに対する変更に関する説明を参照してください。

7.8.3 実効権限情報の取得

Directory Serverで提供されるアクセス制御モデルでは、異なる多くのメカニズムを通じてユーザーにアクセス権を付与できます。ただし、この柔軟性によって、セキュリティ・ポリシーが非常に複雑になる可能性があります。IPアドレス、マシン名、時刻および認証方式など、いくつかのパラメータによって、あるユーザーのセキュリティ・コンテキストを定義できます。

セキュリティ・ポリシーを単純化するために、Directory Serverでは、指定されたディレクトリ・エントリおよび属性に対する、ある特定のユーザーの実効アクセス権を要求および一覧表示できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の実効権限の表示に関する説明を参照してください。

7.8.4 ACIの使用上のヒント

ディレクトリのセキュリティ・モデルを単純化し、ディレクトリのパフォーマンスを改善するためのヒントを次に示します。

- ディレクトリ内のACIの数を最小化し、可能な場合はマクロACIを使用します。
Directory Serverでは50,000件を超えるACIを評価できますが、数多くのACI文を管理することは、困難になる場合があります。また、過剰なACIはメモリー消費にも悪影響を及ぼす可能性があります。

- 許可権限と拒否権限のバランスを取ります。
デフォルトのルールは、アクセスを具体的に許可されていないすべてのユーザーのアクセスを拒否することです。ただし、ツリーのルートの近くでアクセスを許可する1つのACIを使用し、リーフ・エントリの近くで少数の拒否ACIを使用することで、ACIの数を削減できます。この方法で、リーフ・エントリの近くに過剰な数の許可ACIが存在しないようにできます。

- ある特定のACIに対し、属性の最小のセットを識別します。
オブジェクトの属性のサブセットにアクセスを許可または拒否する場合、許可する属性のセットまたは拒否する属性のセットのどちらが最小のリストであるかを判別します。次に、最小リストを管理するようにACIを表します。

たとえば、ユーザー・オブジェクト・クラスに多くの属性が含まれているとします。いくつかの属性のみをユーザーが更新できるようにするには、その少数の属性に対してのみ書込みアクセス権を許可するACIを作成します。1つまたは2つの属性以外のすべてをユーザーが更新できるようにする場合は、それらの1つまたは2つの属性に対する書込みアクセス権を拒否するACIを作成します。

- LDAP検索フィルタは慎重に使用します。
検索フィルタでは、アクセス管理対象のオブジェクトを直接指定しません。したがって、特に、ディレクトリが複雑化すると、検索フィルタによって予期しない結果が発生する場合があります。ACI内で検索フィルタを使用する場合、その同じフィルタを使用してldapsearch操作を実行してください。このアクションにより、その変更の結果がユーザーのディレクトリにとって何を意味するのかを確認できます。

- ディレクトリ・ツリーの異なる部分で、ACIが重複しないようにします。
重複しているACIを探します。ディレクトリのルート・ポイントに、commonNameおよびgivenName属性へのグループ書込みアクセス権を許可するACIがあるとします。さらに、commonName属性のみへの、同じグループ書込みアクセス権を許可する別のACIもあるとします。この場合、そのグループに対して1つの属性のみの書込みアクセス権を付与するように、ACIを修正することを検討してください。

ディレクトリが複雑化するのに伴い、ACIの重複が偶然に発生しやすくなります。ACIの重複を回避することで、セキュリティの管理が容易になり、ディレクトリ内のACIの合計数も減少します。

- ACIに名前を付けます。
ACIに名前を付けることは省略可能ですが、各ACIに意味のある短い名前を付けることで、セキュリティ・モデルの管理が容易になります。

- ユーザー・エントリの標準属性を使用して、アクセス権を決定します。
可能なかぎり、すでに標準ユーザー・エントリの一部となっている情報を使用して、アクセス権を決定してください。特別な属性を作成する必要がある場合は、それらの属性をロールまたはサービス・クラス(CoS)の定義の一部として作成することを検討します。ロールおよびCoSの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第11章「Directory Serverのグループおよびロール」およびOracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。

- ACIできるだけ近い位置にまとめます。
ACIの配置をディレクトリのルート・ポイントとディレクトリの主なブランチ・ポイントに限定します。ACIを編成してグループにまとめると、ACIリストの全体を簡単に管理できるようになり、ACIの合計数を最小に保つことができます。

- 二重否定の使用を避けます(バインドDNがcn=Joeと等しくない場合の書込みの拒否など)。
この構文はサーバーでは許容されますが、管理者にとっては混乱の元となります。

7.9 接続ルールによるアクセス制御の設計

接続ルールを使用すると、選択されたクライアントでDirectory Serverへの接続が確立されないようにできます。接続ルールの目的は、Directory Serverに接続してサーバーをリクエストであふれさせる、悪意のあるクライアントや適切に設計されていないクライアントによって引き起こされるサービス拒否攻撃を防止することです。

接続ルールは、TCPラッパーを定義することによって、TCPレベルで確立されます。TCPラッパーの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のTCPラップによるクライアント・ホスト・アクセス制御に関する説明を参照してください。

7.10 Directory Proxy Serverによるアクセス制御の設計

Directory Proxy Serverの接続ハンドラでは、クライアントからの着信接続の分類を可能にするアクセス制御の方法を提供します。この方法では、接続がどのように分類されたかに基づいて、実行可能な操作を制限できます。

この機能を使用すると、たとえば、ある指定されたIPアドレスから接続するクライアントのみにアクセスを制限できます。次の図は、Directory Proxy Serverの接続ハンドラを使用して特定のIPアドレスからの書込み操作を拒否する方法を示したものです。

図7-2 Directory Proxy Serverの接続ハンドラのロジック

「図7-2 Directory Proxy Serverの接続ハンドラのロジック」の説明

7.10.1 接続ハンドラの動作

接続ハンドラは、一連の基準および一連のポリシーで構成されます。Directory Proxy Serverでは、接続の起点属性をクラスの基準と照合することにより、その接続のクラス・メンバーシップを決定します。接続があるクラスに一致すると、Directory Proxy Serverではそのクラスに格納されているポリシーをその接続に適用します。

接続ハンドラの基準には、次のものを含めることができます。

- クライアントの物理アドレス

- ドメイン名またはホスト名

- クライアントDNのパターン

- 認証方式

- SSL

接続ハンドラには次のポリシーを関連付けることができます。

- 管理制限ポリシー。特定の制限(たとえば、ある特定クラスのクライアントからのオープン接続数)を設定できます。

- コンテンツ適応ポリシー。属性の名前変更など、接続で実行できる操作の種類を制限できます。

- データ分散ポリシー。接続で特定の配布スキームを使用できるようにします。

Directory Proxy Serverの接続ハンドラおよびその設定方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第20章「クライアントとDirectory Proxy Server間の接続」を参照してください。

7.11 エントリの安全なグループ化

ロールおよびCoSでは、セキュリティに関する特別な考慮が必要となります。

7.11.1 ロールの安全な使用方法

ロールの中には、セキュリティ・コンテキスト内での使用に適していないものがあります。ロールを作成するときは、エントリへのロールの割当てやエントリからのロールの削除がどの程度簡単に実行できるかを考慮します。ユーザーは、場合によっては、自分自身をロールに追加したりロールから削除できる必要があります。ただし、一部のセキュリティ・コンテキストには、そのようなオープンなロールは適しません。詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverのロールに関する説明を参照してください。

7.11.2 CoSの安全な使用方法

読取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービス・クラス(CoS)メカニズムによって生成される仮想属性は、通常の属性と同様に読み取られます。したがって、仮想属性には、同じ方法で読取り保護を付与する必要があります。ただし、CoS値をセキュリティ保護するには、CoS値で使用されるすべての情報ソース(定義エントリ、テンプレート・エントリおよびターゲット・エントリ)を保護する必要があります。更新操作についても同じです。各情報ソースから生成される値を保護するには、それらのソースへの書込みアクセス権を制御する必要があります。詳細は、Oracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。

7.12 ファイアウォールの使用

ファイアウォール・テクノロジは、通常、内部ネットワークを出入りするネットワーク・トラフィックをフィルタリングまたはブロックするために使用されます。LDAPリクエストが境界ファイアウォールの外側から送信される場合には、ファイアウォールの通過を許可するポートとプロトコルを指定する必要があります。

指定するポートとプロトコルはディレクトリのアーキテクチャによって異なります。一般的に、ポート389および636上のTCPおよびUDP接続を許可するように、ファイアウォールを構成する必要があります。

Directory Serverが稼働しているのと同じサーバーに、ホストベースのファイアウォールをインストールできます。ホストベースのファイアウォールのルールは、境界防御ファイアウォールのルールと類似しています。

7.13 root以外として実行

サーバー・インスタンスをroot以外のユーザーとして作成および実行できます。サーバー・インスタンスをroot以外のユーザーとして実行することで、悪用によって発生する可能性のあるすべての損害を制限できます。さらに、root以外のユーザーとして実行されるサーバーは、オペレーティング・システムのアクセス制御メカニズムの処理対象となります。

7.14 その他のセキュリティ・リソース

セキュリティ保護されたディレクトリの設計の詳細は、次のリソースを参照してください。

- Sun Developer Security Resources (http://developers.sun.com/techtopics/security/index.html) (http://java.sun.com/javase/technologies/security/)

- 『Understanding and Deploying LDAP Directory Services』T.Howes、M. Smith、G. Good、Macmillan Technical Publishing、1999

- SecurityFocus.com (http://www.securityfocus.com/) (http://www.securityfocus.com/)

- Computer Emergency Response Team (CERT) Coordination Center (http://www.cert.org/) (http://www.cert.org/)

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

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

- 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つのコンポーネントで構成されます。

- DSCC Webインタフェース

- DSCCエージェント

- DSCCレジストリ

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管理者専用の接続ハンドラが作成され、dccAdminSuffixがcn=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.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 オフラインのバイナリ・バックアップ」の説明

バイナリ・バックアップのコマンドを使用する方法の詳細は、『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 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.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 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 監視方針の設計

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

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

- 適切な監視ツールを選択します。「Directory Server Enterprise Editionで提供される監視ツール」を参照してください。

- ディレクトリ・アーキテクチャ内で、監視対象とする主な領域を特定します。
これらの領域は、一般的にサイズ設定やチューニングの属性と同じになります。「監視領域の特定」を参照してください。

- 重要なパフォーマンス指標を監視する場合に、イベントまたはアラーム状態をトリガする条件を定義します。
この方針を採用する場合は、許容できるパフォーマンスのレベル、または各パフォーマンス指標に対する操作を定義します。

- アラーム状態が発生したときに実行するアクションを決定します。

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には、接続およびそれぞれの連鎖する接尾辞で実行される操作に関する情報も表示されます。

- レプリケーション監視ツール。コマンドライン・ツール、repldisc、insyncおよびentrycmpが含まれます。
これらのツールを使用すると、次のことを実行できます。

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

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

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

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

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

- Simple Network Management Protocol (SNMP)。グローバルなネットワークの制御と監視のための標準メカニズムであり、ネットワーク管理者がネットワーク監視アクティビティを一元的に実行できます。
SNMPエージェントを使用した監視の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第15章「Directory Serverの監視」を参照してください。

8.4.2 監視領域の特定

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

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

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

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

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

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

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

第III部

論理設計

論理アーキテクチャでは、Directory Server Enterprise Editionデプロイメントのコンポーネントを特定し、コンポーネント間の相互関係を示します。通常、デプロイメントに必要なコンポーネントは、技術要件フェーズで作成するユースケースによって示されます。ただし、多くの場合、必要なコンポーネントはビジネス要件から直接導出できます。

ここでは、一般的なDirectory Server Enterprise Editionデプロイメント・シナリオに基づくサンプル論理アーキテクチャを示します。この部の情報は、基本的な単一サーバー・デプロイメントから、複数のデータ・センターにわたる複雑なデプロイメントに関する情報です。この部の後半の章で説明するアーキテクチャは、前半の章で説明する単純なアーキテクチャに基づいています。

次の章で構成されています。

- 第9章「基本デプロイメントの設計」では、基本的なDirectory Server Enterprise Editionデプロイメントについて説明します。

- 第10章「スケーラビリティを持つデプロイメントの設計」では、追加のサービス要件を満たすように拡張されたデプロイメントについて説明します。

- 第11章「グローバル・デプロイメントの設計」では、複数のデータ・センターをまたぐデプロイメントの考慮事項について説明します。

- 第12章「高可用性デプロイメントの設計」では、可用性要件を満たすように設計されたデプロイメントについて説明します。

9 基本的なデプロイメントの設計

最も単純なDirectory Server Enterprise Editionデプロイメントでは、単一のデータ・センター内の1台のマシンに単一のDirectory Serverをインストールすることによって、ディレクトリ・サービス要件を満たすことができます。このようなシナリオは、小規模組織、またはデモや評価の目的でDirectory Serverを実行する場合に発生することがあります。前の章で説明した技術要件は、すべてのデプロイメントに同等に適用されます。

この章では、単一のDirectory Serverが含まれた、基本的なデプロイメントについて説明します。この章の内容は次のとおりです。

- 基本的なデプロイメントのアーキテクチャ

- 基本的なデプロイメントの設定

- 基本的なデプロイメントのパフォーマンスの改善

9.1 基本的なデプロイメントのアーキテクチャ

基本的なDirectory Server Enterprise Editionデプロイメントには、次の要素が含まれます。

- Directory Serverインスタンス・ファイル

- Directory Serverデーモン

- dsadmおよびdsconfコマンドライン・ユーティリティ

- Directory Service Control Center (DSCC) (GUIアクセスが必要な場合)

- DSCCエージェント(DSCCを使用する場合)

これらの要素は、単一のマシンにすべてインストールできます。次の図は、基本的なDirectory Server Enterprise Editionデプロイメントの概略レベルのアーキテクチャを示しています。

図9-1 単一のマシン上の基本的なDirectory Server Enterprise Editionのアーキテクチャ

「図9-1 単一のマシン上の基本的なDirectory Server Enterprise Editionのアーキテクチャ」の説明

このシナリオでは、内部のLDAPおよびDSMLクライアントをDirectory Serverに直接アクセスするように構成できます。外部のHTMLクライアントは、ファイアウォールを介してDSCCにアクセスするように構成できます。

前に説明したコンポーネントは単一のマシンにすべてインストールできますが、実際のデプロイメントでは、通常、このようにはしません。一般的なシナリオでは、DSCCおよびdsconfコマンドライン・ユーティリティは別々のリモート・マシンにインストールされます。これらのマシンからリモートですべてのDirectory Serverホストを構成できます。次の図は、この一般的なシナリオを示しています。

図9-2 リモートのDirectory Service Control Centerを使用した基本的なDirectory Server Enterprise Editionのアーキテクチャ

「図9-2 リモートのDirectory Service Control Centerを使用した基本的なDirectory Server Enterprise Editionのアーキテクチャ」の説明

Directory Serverインスタンスには、サーバーとアプリケーションの構成設定およびユーザー情報が格納されます。通常、サーバーおよびアプリケーションの構成情報はDirectory Serverの1つの接尾辞に格納され、ユーザーおよびグループ・エントリは別の接尾辞に格納されます。接尾辞は、ディレクトリ・ツリー内のエントリの名前を指し、その下にデータが格納されます。

Directory Service Control Center (DSCC)は、すべてのサーバーのための集中管理されたWebベースのユーザー・インタフェースです。DSCCによって、登録されているすべてのサーバーおよびアプリケーションが特定されます。DSCCには、サーバーがグラフィカル・ユーザー・インタフェースに表示され、そこでサーバーを管理および構成できます。小規模のデプロイメントでは、すべての機能がコマンドライン・インタフェースでも提供されるため、Directory Service Control Centerが必要ない場合もあります。

以降の章では、Directory Service Control Centerが別のマシンにインストールされていることを想定しています。トポロジのこの側面については、残りの章で再び記述されることはありません。

9.2 基本的なデプロイメントの設定

インストールの詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』を参照してください。この項の目的は、基本的なデプロイメントを構成する要素を明確にし、これらの要素の連携について説明することです。

この項では、前の項で説明した基本的なデプロイメントを設定するための主なタスクを示します。

- Directory Server、DSCCエージェントおよびコマンドライン・インタフェースをインストールします。

- コマンドライン・ユーティリティを使用してサーバーを管理する場合は、次のことを実行します。

- dsadmコマンドを使用して、スタンドアロンDirectory Serverインスタンスを作成し、起動します。

- dsconfコマンドを使用して、新しいインスタンスの接尾辞を作成し、構成します。

- グラフィカル・ユーザー・インタフェースを使用してサーバーを管理する場合は、次のことを実行します。

- Directory Service Control Centerを初期化します。

- Directory Service Control Centerを使用して、Directory Serverインスタンスを作成します。

- Directory Service Control Centerを使用して、新しいインスタンスの接尾辞を作成し、構成します。

9.3 基本的なデプロイメントのパフォーマンスの改善

最も基本的なデプロイメントでも、特定の領域のパフォーマンスを改善するためにDirectory Serverをチューニングすることが必要となる場合があります。次の各項では、単純な単一サーバー・デプロイメントに適用できる基本的なチューニング方針について説明します。より大規模で複雑なデプロイメントの各サーバーにこれらの方針を適用すると、トポロジ全体のパフォーマンスを改善できます。

9.3.1 索引作成による検索の高速化

索引を使用すると、検索で一致を見つけるために確認する必要があるエントリの数が効果的に削減されるため、検索が高速化されます。索引には、値のリストが含まれます。各値は、エントリ識別子のリストに関連付けられます。Directory Serverでは、索引のエントリ識別子のリストを使用して、迅速にエントリを検索できます。エントリのリストを管理するための索引がない場合、Directory Serverでは、接尾辞のすべてのエントリを確認して検索の一致を見つける必要があります。

Directory Serverは、各検索リクエストを次のように処理します。

1. Directory Serverは、クライアントから検索リクエストを受信します。

2. Directory Serverはリクエストを調べ、検索を処理できることを確認します。
検索を実行できない場合は、クライアントにエラーを返し、Directory Serverの別のインスタンスに検索を委ねることがあります。

3. Directory Serverは、検索に適した1つ以上の索引を管理するかどうかを決定します。

- Directory Serverで検索に適した索引を管理する場合、サーバーは適切なすべての索引を調べて候補エントリを検索します。候補エントリは、検索リクエストに一致する可能性があるエントリです。

- Directory Serverで検索に適した索引を管理しない場合、サーバーはデータベース内のエントリをすべて確認して一連の候補エントリを生成します。
Directory Serverで索引を使用できない場合は、このプロセスで消費される時間およびシステム・リソースが増大します。

4. Directory Serverでは、エントリが検索基準に一致するかどうかを判断するために、それぞれの候補エントリを調べます。

5. 一致するエントリが見つかると、Directory Serverによってクライアント・アプリケーションに返されます。

検索パフォーマンスは、次の方法で最適化できます。

- Directory Serverで索引付けされていないエントリに対して検索を実行しないようにします。

- キャッシュ・サイズが適切にチューニングされていることを確認します。

- 索引の長さを制限します。

索引の動作の包括的な概要は、Oracle Directory Server Enterprise Editionリファレンスの第9章「Directory Serverの索引作成」を参照してください。索引の定義の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第12章「Directory Serverの索引作成」を参照してください。

9.3.2 検索パフォーマンスのためのキャッシュの最適化

検索パフォーマンスを改善するには、できるだけ多くのディレクトリ・データをメモリーにキャッシュします。ディレクトリによってディスクから情報が読み取られないようにすることによって、ディスクI/Oのボトルネックを制限します。このことを行う場合、ディレクトリ・ツリーのサイズ、使用可能なメモリーの量および使用されるハードウェアによって、様々な方法があります。デプロイメントに応じて、検索パフォーマンスを最適化するために、エントリおよびデータベース・キャッシュに割り当てるメモリーを増減することを選択できます。または、異なるサーバー上の複数のDirectory Serverコンシューマに検索を分散することもできます。

詳細は、「キャッシュ設定のチューニング」を参照してください。

次のシナリオを検討してください。

- すべてのエントリと索引がメモリーに収まる場合

- 32ビットDirectory Serverのため十分なメモリーがある場合

- メモリー不足

9.3.2.1 すべてのエントリと索引がメモリーに収まる場合

最適なケースでは、データベース・キャッシュおよびエントリ・キャッシュは使用可能な物理メモリーに収まります。エントリ・キャッシュは、ディレクトリ内のすべてのエントリを格納できる大きさです。データベース・キャッシュは、すべての索引およびエントリを格納できる大きさです。このケースでは、すべての検索対象がキャッシュにあります。Directory Serverがファイル・システム・キャッシュまたはディスクにアクセスしてエントリを取得する必要はありません。

更新および拡張の後も、データベース・キャッシュにすべてのデータベース索引を格納できることを確認してください。データベース・キャッシュに索引のための領域がなくなると、Directory Serverは検索リクエストのたびにディスクから索引を読み取る必要があり、スループットに大きな影響を及ぼします。DSCCまたはコマンドラインを使用して、ページングおよびキャッシュ・アクティビティを監視できます。

適切なキャッシュ・サイズは、代表的なデータを使用して実験的にテストして決定する必要があります。通常、データベース・キャッシュのサイズは、(total size of database files) x 1.2で計算できます。まず、キャッシュに大量のメモリーを割り当てます。次に、Directory Serverを実行および監視して結果を確認し、必要に応じて処理を繰り返します。特に、エントリ・キャッシュでは、これらのキャッシュに割り当てた量よりはるかに多いメモリーが使用されることがあります。

エントリ・キャッシュは、サーバーの負荷によって1分間にアクセスされたエントリの数がすぐにわかるような方法で、測定する必要があります。エントリ・キャッシュの内容が1秒間に何度も置き換えられる状況は回避するようにしてください。

9.3.2.2 32ビットDirectory Serverのため十分なメモリーがある場合

エントリ・キャッシュおよびデータベース・キャッシュ内のすべてのデータを格納するための十分なメモリーが搭載され、64ビットDirectory Serverプロセスがサポートされていないシステムの場合を考えます。ハードウェアの制約により、64ビットをサポートするSolarisシステムにDirectory Serverをデプロイできない場合は、32ビット・プロセスのメモリー制限に合わせてキャッシュのサイズを適切に調整します。次に、残りのメモリーをファイル・システム・キャッシュに残します。

パフォーマンスのベンチマークを実行する場合は、最初に、できるだけ多くのエントリが格納されるようにエントリ・キャッシュのサイズを調整します。データベース・キャッシュのサイズは、完全に最小にするのではなく、ファイル・システムがデータベース・ページを格納できるように、100MBなどの比較的小さいサイズにします。

注意:

ファイル・システム・キャッシュは、システム上の他のプロセス(特にファイルベースの操作)で共有されます。このため、特に、Directory Server専用でないシステムでは、ファイル・システム・キャッシュの制御は、他のキャッシュの制御よりも困難になります。

ファイル・システム・キャッシュは、システムによって他のプロセスに再割当てされることがあります。

Directory Serverプロセスにはインポート・キャッシュが関連付けられているため、この状況ではオンライン・インポートを実行しないでください。

9.3.2.3 メモリー不足

エントリ・キャッシュおよびデータベース・キャッシュ内のすべてのデータを格納するためのメモリーが不足しているシステムを考えます。この場合は、エントリ・キャッシュ・サイズとデータベース・キャッシュ・サイズの合計が使用可能な物理メモリーのサイズを超えることがないようにしてください。これにより、仮想メモリーのページングが大量に発生し、システムが仮想停止する可能性があります。

小規模システムの場合は、使用可能なメモリーをエントリ・キャッシュおよびデータベース・キャッシュ(それぞれ100MB未満のサイズ)に使用してベンチマークを開始します。mount_ufsコマンドの-o forcedirectioオプションを使用してSolaris UFSファイル・システムをマウントすることで、ファイル・システム・キャッシュを無効にします。詳細は、mount_ufs(1M)のマニュアル・ページを参照してください。ファイル・システム・キャッシュを無効にすると、Directory Serverで必要になるメモリーがファイル・システム・キャッシュによって使用されることを防止できます。

大規模なマシンでDirectory Serverが実行されている場合は、ファイル・システム・キャッシュを最小にし、データベース・キャッシュを減らします。実験的にテストして想定を検証し、修正します。

9.3.3 書込みパフォーマンスのためのキャッシュの最適化

デプロイメントを計画するとき、最初から書込みスケーラビリティが確保されるようにする以外に、データベース・キャッシュにメモリー内の更新を処理するための十分なメモリーを割り当てます。また、ディスク・アクティビティを最小化します。データベース・キャッシュの効果は、Directory Service Control Centerでヒット率を読むことによって監視できます。

Directory Serverをしばらくの間実行すると、キャッシュに十分なエントリと索引が格納されて、ディスク読取りが必要なくなります。更新はメモリー内のデータベース・キャッシュに影響を及ぼし、メモリー内の大規模なデータベース・キャッシュのデータはまれにしかフラッシュされません。

チェックポイント中のディスクへのデータ・フラッシュは、ボトルネックになることがあります。データベース・キャッシュ・サイズが大きくなるほど、ボトルネックは大きくなります。データベースをSun StorEdgeディスク・アレイなどの別のRAIDシステムに格納すると、更新パフォーマンスの改善に役立つ場合があります。Solarisシステムでiostatなどのユーティリティを使用して、可能性のあるI/Oボトルネックを特定できます。詳細は、iostat(1M)のマニュアル・ページを参照してください。

次の表に、2、3および4つのディスクのあるシステムにおけるデータベースおよびログの配置の推奨事項を示します。

表9-1 様々なディスクにおけるデータベースとログの分離

使用可能なディスク

推奨事項

2

- Directory Serverデータベースを一方のディスクに配置します。

- トランザクション・ログ、アクセス・ログ、監査ログ、エラー・ログおよびレトロ変更ログをもう一方のディスクに配置します。

3

- Directory Serverデータベースを一方のディスクに配置します。

- トランザクション・ログを2つ目のディスクに配置します。

- アクセス・ログ、監査ログ、エラー・ログおよびレトロ変更ログを3つ目のディスクに配置します。

4

- Directory Serverデータベースを一方のディスクに配置します。

- トランザクション・ログを2つ目のディスクに配置します。

- アクセス・ログ、監査ログおよびエラー・ログを3つ目のディスクに配置します。

- レトロ変更ログを4つ目のディスクに配置します。

10 スケーラビリティを持つデプロイメントの設計

第9章「基本的なデプロイメントの設計」で説明した基本的なデプロイメントでは、単一のDirectory Serverで組織の読取りおよび書込み要件を十分に満たすことができることを想定しています。大規模な読取りおよび書込み要件がある組織、つまり、複数のクライアントがディレクトリ・データに同時にアクセスを試みる場合は、スケーラビリティを持つデプロイメントを使用する必要があります。

通常、すべてのデータをキャッシュできる十分なメモリーがある場合、1つのDirectory Serverインスタンスで1秒間に実行できる検索の数は、サーバーのCPUの数と速度に直接関連します。負荷を複数のサーバーに分散することによって、水平方向の読取りスケーラビリティを実現できます。このことは、通常、クライアントが複数のソースからデータを読み取ることができるように、データの追加コピーを提供することを意味します。

マスター・サーバーに対して書込み操作を実行すると、書込み操作がすべてのレプリカに対して実行されるため、書込み操作には水平方向のスケーラビリティがありません。書込み操作を水平方向に拡張する方法は、ディレクトリ・データを複数のデータベースに分割し、それらのデータベースを別々のサーバーに配置することのみとなります。

この章では、Directory Server Enterprise Editionデプロイメントを拡張してより多くの読取りおよび書込みを処理するための様々な方法について説明します。この章の内容は次のとおりです。

- 読取りスケーラビリティのためのロード・バランシングの使用

- 書込みスケーラビリティのための分散の使用

- 分散のためのリフェラルの使用

10.1 読取りスケーラビリティのためのロード・バランシングの使用

ロード・バランシングでは、読取り負荷を複数のサーバーに分散することによって、パフォーマンスを改善します。ロード・バランシングを実現するには、レプリケーション、Directory Proxy Serverまたはこれらの2つの組合せを使用します。

10.1.1 ロード・バランシングのためのレプリケーションの使用

レプリケーションは、ディレクトリ・データを自動的にコピーし、あるディレクトリ・サーバーから別のディレクトリ・サーバーに移動するためのメカニズムです。レプリケーションを使用すると、独自の接尾辞に格納されたディレクトリ・ツリーまたはサブツリーをサーバー間でコピーできます。

注意:

構成情報または監視情報のサブツリーはコピーできません。

ディレクトリ・データを複数のサーバーにレプリケートすることで、単一のマシンのアクセス負荷を軽減できるため、サーバーのレスポンス時間が短縮され、読取りスケーラビリティが確保されます。また、ディレクトリ・エントリをユーザーに近い場所にレプリケートすると、ディレクトリのレスポンス時間が短縮されます。レプリケーションは、通常、書込みスケーラビリティを実現するためのソリューションではありません。

10.1.1.1 基本的なレプリケーション概念

レプリケーション・メカニズムの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」に記載されています。次の項では、この章で後述されているサンプル・トポロジを確認する前に理解する必要がある基本情報を示します。

10.1.1.1.1 マスター・レプリカ、コンシューマ・レプリカおよびハブ・レプリカ

レプリケーションに関連するデータベースは、レプリカとして定義されています。

Directory Serverでは、3種類のレプリカが区別されます。

- マスターまたは読取り/書込みレプリカ。ディレクトリ・データのマスター・コピーが格納されている読取り/書込みデータベースです。マスター・レプリカでは、ディレクトリ・クライアントからの更新リクエストを処理できます。複数のマスターが含まれているトポロジは、マルチマスター・トポロジと呼ばれます。

- コンシューマ・レプリカ。マスター・レプリカ内の情報のコピーが格納されている読取り専用データベースです。コンシューマ・レプリカでは、ディレクトリ・クライアントからの検索リクエストを処理できますが、更新リクエストはマスター・レプリカに委任します。

- ハブ・レプリカ。1つ以上のコンシューマ・レプリカを提供するDirectory Serverに格納されている、(コンシューマ・レプリカと同様に)読取り専用データベースです。

次の図は、レプリケーション・トポロジにおけるこれらのレプリカのそれぞれの役割を示しています。

図10-1 レプリケーション・トポロジにおけるレプリカの役割

「図10-1 レプリケーション・トポロジにおけるレプリカの役割」の説明

注意:

前の図は、説明のみを目的とし、必ずしも推奨トポロジを示すものではありません。Directory Serverでは、マルチマスター・トポロジにおける無制限のマスター数がサポートされています。多くの場合、マスターのみのトポロジが推奨されます。

10.1.1.2 初期レプリケーション要件の評価

ディレクトリ・サービスを適切にレプリケートするには、本番環境における包括的なテストおよび分析が必要です。ただし、次の基本計算により、レプリケートされたトポロジの設計を開始できます。次の各項では、この計算の結果をレプリケートされたトポロジ設計の基礎として使用します。

10.1.1.2.1 初期レプリケーション要件の特定

1. ピーク使用時に必要な1秒当たりの最大検索数を見積もります。
この見積りを検索数合計と呼びます。

2. 単一のホストで実行できる1秒当たりの検索数をテストします。
この見積りをホスト当たりの検索数と呼びます。これは、レプリケーションを有効にして評価する必要があります。

ホストで実行できる検索の数は、複数の変数の影響を受けます。これらの中には、エントリのサイズ、ホストの容量およびネットワークの速度があります。これらのテストの実行に役立つ多くのサード・パーティのパフォーマンス・テスト・ツールを使用できます。SLAMD分散負荷生成エンジンは、ネットワークベースのアプリケーションの負荷テストおよびパフォーマンス分析のために設計されたオープン・ソースのJavaアプリケーションです。SLAMDを効果的に使用して、レプリケーション評価のこの部分を実行できます。SLAMDの詳細およびSLAMDソフトウェアのダウンロード方法は、http://www.slamd.com (http://www.slamd.com/)を参照してください。

3. 必要なホストの数を計算します。
ホストの数 = 検索数合計 / ホスト当たりの検索数

10.1.1.3 単一のデータ・センターにおけるマルチマスター・レプリケーションを使用したロード・バランシング

レプリケーションでは、次の方法でDirectory Serverの負荷のバランスを取ることができます。

- 検索アクティビティを複数のサーバーに分散します。

- 特定のサーバーを特定のタスクまたはアプリケーション専用にします。

通常、「初期レプリケーション要件の評価」で計算したホストの数が約16の場合、またはそれほど大きくない場合は、完全接続トポロジにマスター・サーバーのみを含める必要があります。完全接続とは、すべてのマスターがトポロジ内の他のすべてのマスターにレプリケートされていることを意味します。

注意:

ホストの数は概算であり、デプロイメントのハートウェアやその他の詳細によって異なります。

次の図では、ホストの数が2であることを想定しています。LDAP操作は、クライアント・アプリケーションのタイプに基づいて2つのマスター・サーバー間で分割されます。この方針によって、各サーバーの負荷が減少し、デプロイメントで処理できる操作の合計数が増加します。

図10-2 ロード・バランシングのためのマルチサーバー・レプリケーションの使用

「図10-2 ロード・バランシングのためのマルチサーバー・レプリケーションの使用」の説明

グローバル・デプロイメントにおける同様のシナリオは、第11.1.1.2項「WAN経由のマルチマスター・レプリケーション」を参照してください。

10.1.1.4 大規模デプロイメントにおけるレプリケーションを使用したロード・バランシング

デプロイメントに必要なホストの数が16を大幅に超過する場合は、トポロジへの専用コンシューマの追加が必要になることがあります。

次の図では、ホストの数が24であることを想定し、わかりやすくするためにトポロジの一部のみを示しています。残りの10個のサーバーは同じ構成で、合計で8つのマスター、16個のコンシューマがあります。

図10-3 大規模デプロイメントにおけるロード・バランシングのためのマルチサーバー・レプリケーションの使用

「図10-3 大規模デプロイメントにおけるロード・バランシングのためのマルチサーバー・レプリケーションの使用」の説明

次のことを実行する必要がある場合は、これらのコンシューマのいずれかで変更ログを有効にできます。

- 停止が発生した場合に、コンシューマをマスターに昇格します。

- マスターからいずれかのコンシューマに対してバイナリ初期化を実行します。

ホストの数が数百になる場合は、トポロジへのハブの追加が必要になることがあります。このような場合は、マスターよりもハブを多くし、マスターごとに最大10個のハブを用意します。各ハブでは、最大20コンシューマに対するレプリケーションを処理する必要があります。

トポロジのハブの数をマスターまたはコンシューマと同じにすることはできません。

注意:

マルチマスター・トポロジで一方向のマスター(レプリケーションの変更を受信するが、送信しないマスター)を構成することは、そのマスターへのレプリケーションが中断される可能性があるため、お薦めしません。

10.1.1.5 サーバー・グループを使用したマルチマスター・トポロジの簡略化

ホストの数が大きい場合は、サーバー・グループを使用すると、トポロジを簡略化したり、リソース使用率を改善できます。16個のマスターを含むトポロジでは、16個のフルメッシュ・マスターよりも4つのサーバー・グループ(それぞれ4つのマスターを含む)を使用した方が管理しやすくなります。

このようなトポロジは、次の手順で設定します。

- レプリケーション承諾のない16個のマスターを構成します。

- 4つのサーバー・グループを作成し、各グループに4つのマスターを含めます。

- 単一グループ内にあるすべてのマスター間のレプリケーション承諾を設定します。

- 各グループの最初のマスター、各グループの2番目のマスターなどの間のレプリケーション承諾を設定します。

次の図は、その結果のトポロジを示しています。

図10-4 マルチマスター・トポロジ内のサーバー・グループ

「図10-4 マルチマスター・トポロジ内のサーバー・グループ」の説明

10.1.2 ロード・バランシングのためのDirectory Proxy Serverの使用

Directory Proxy Serverでは、複数のサーバーを使用して単一のデータ・ソースの負荷を分散できます。また、いずれかのサーバーが使用できなくても、データが使用できる状態を維持することもできます。Directory Proxy Serverによって、データの分散以外に、操作ベースのロード・バランシングが提供されます。つまり、サーバーは、クライアント操作を操作のタイプに基づいて特定のDirectory Serverにルーティングできます。

Directory Proxy Serverでは、操作ベースのロード・バランシング、およびDirectory Server間におけるワークロードの共有方法を決定する様々なロード・バランシング・アルゴリズムがサポートされています。これらの各アルゴリズムの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第16章「Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ」を参照してください。

次の図は、比例アルゴリズムを使用して、2つのサーバーの間で読取り負荷のバランスを取る方法を示しています。サーバーで障害が発生しないかぎり、操作ベースのロード・バランシングによって、すべての書込みはマスター1にルーティングされます。障害が発生すると、すべての読取りおよび書込みはマスター2にルーティングされます。

図10-5 スケーラビリティを持つデプロイメントにおける比例および操作ベース・ロード・バランシングの使用

「図10-5 スケーラビリティを持つデプロイメントにおける比例および操作ベース・ロード・バランシングの使用」の説明

1つのサーバー・インスタンスで障害が発生した場合、ロード・バランシングの構成は再計算されません。比例ロード・バランシングを使用して、サーバーのロード・バランシングの重みを0に設定することでホット・スタンバイ・サーバーを作成することはできません。

たとえば、3つのサーバーA、BおよびCがある場合を考えます。サーバーAおよびBがそれぞれ負荷の50%を受信するように比例ロード・バランシングが構成されています。サーバーCは、スタンバイ・サーバー専用として設計されているため、負荷は0%になるように構成されています。サーバーAで障害が発生すると、負荷の100%は自動的にサーバーBに移動されます。サーバーBでも障害が発生した場合にのみ、負荷はサーバーCに分散されます。したがって、インスタンスは常にロード・バランシングに参加して常に負荷の一部を担当できる状態であるか、または、すべてのプライマリ・インスタンスで障害が発生した場合はそのサーバーが負荷を引き継ぎます。

飽和ロード・バランシング・アルゴリズムを使用し、スタンバイ・サーバーに適用する重みを低くすることで、ホット・スタンバイに似た処理を実行できます。サーバーは本来のスタンバイ・サーバーではありませんが、プライマリ・サーバーの負荷が大きい場合にのみ、リクエストがこのサーバーに分散されるようにアルゴリズムを構成できます。事実上、1つのプライマリ・サーバーが無効になっている場合は、他のプライマリ・サーバーの負荷が増大するため、リクエストをスタンバイ・サーバーに分散することが必要となります。

10.2 書込みスケーラビリティのための分散の使用

書込み操作では、リソースが大量に使用されます。クライアントが書込み操作をリクエストすると、データベースで次の一連のイベントが発生します。

- バックエンド・データベースがロックされます。

- エントリがデータベース・キャッシュでロックされます。

- アクセス制御チェック・プラグインが呼び出されます。

- バックエンドの操作前プラグインが呼び出されます。

- データベース・トランザクションが開始されます。

- データベース・ファイルが更新されます。

- 古いエントリ・キャッシュが新しいデータに置き換えられます。

- データベース・トランザクションがコミットされます。

- バックエンドの操作後プラグインが呼び出されます。

- バックエンド・データベースのロックが解除されます。

この複雑な手順によって書込みの回数が増加するため、パフォーマンスへの重大な影響が発生する場合があります。

企業の成長に伴い、より多くのクライアント・アプリケーションからの、ディレクトリへの迅速な書込みアクセスが必要になります。また、単一のDirectory Serverに格納される情報が増加することにより、ディレクトリ・データベース内のエントリの追加または変更のコストが増大します。これは、索引が大きくなり、索引に含まれる情報の操作に、より長い時間がかかるようになるためです。

場合によっては、メモリーにすべてのデータをキャッシュすることによってのみサービス・レベル合意を達成できます。ただし、データが大きすぎて、単一のメモリー・マシンに収まらないことがあります。

ディレクトリ・データの量がこの程度まで増加した場合は、複数のサーバーに格納できるようにデータを分割する必要があります。1つの方法として、階層を使用して情報を分割することをあげることができます。情報をある基準に基づいて複数のブランチに分割することによって、各ブランチを別のサーバーに格納できます。その後、各サーバーにチェーンまたはリフェラルを構成して、クライアントがシングル・ポイントからすべての情報にアクセスできるようにすることができます。

このように分割する場合、各サーバーはディレクトリ・ツリーの一部のみを担当します。分散されたディレクトリは、ドメイン・ネーム・サービス(DNS)と同じように動作します。DNSでは、DNSネームスペースの各部分が特定のDNSサーバーに割り当てられます。同じ方法で、クライアントの観点から1つのディレクトリ・ツリーを保持したまま、ディレクトリ・ネームスペースを複数のサーバーに分散できます。

階層ベースの分散メカニズムには短所があります。主な問題は、このメカニズムではクライアントが情報の場所を正確に把握している必要があるということです。または、クライアントは、データを見つけるために広範な検索を実行する必要があります。別の問題として、一部のディレクトリ対応アプリケーションには、複数のブランチに分割された情報を処理する機能がありません。

Directory Serverでは、チェーンおよびリフェラル・メカニズムとともに階層ベースの分散がサポートされています。ただし、分散機能は、スマート・ルーティングがサポートされているDirectory Proxy Serverでも提供されています。この機能を使用すると、企業に最適な分散メカニズムを決定できます。

10.2.1 複数のデータベースの使用

Directory Serverでは、データが高パフォーマンスのディスクベースLDBMデータベースに格納されます。各データベースはファイルのセットで構成され、ファイルには、そのセットに割り当てられているすべてのデータが含まれます。ディレクトリ・ツリーの異なる部分を異なるデータベースに格納できます。たとえば、次の図に示すように、ディレクトリ・ツリーに3つのサブ接尾辞が含まれている場合を考えます。

図10-6 3つのサブ接尾辞を含むディレクトリ・ツリー

「図10-6 3つのサブ接尾辞を含むディレクトリ・ツリー」の説明

3つのサブ接尾辞のデータは、次の図に示すように3つの異なるデータベースに格納できます。

図10-7 3つの異なるデータベースに格納された3つのサブ接尾辞

「図10-7 3つの異なるデータベースに格納された3つのサブ接尾辞」の説明

ディレクトリ・ツリーをデータベースに分割すると、データベースを複数のサーバーに分散できます。通常、この方針は複数の物理マシンと同じであり、これにより、パフォーマンスが向上します。前の図の3つのデータベースは、次の図に示すように2つのサーバーに格納できます。

図10-8 2つの異なるサーバーに格納された3つのデータベース

「図10-8 2つの異なるサーバーに格納された3つのデータベース」の説明

データベースを複数のサーバーに分散すると、各サーバーで実行する必要のある作業の量が削減されます。したがって、単一サーバーよりもかなり多くのエントリを保持できるように、ディレクトリを拡張できます。Directory Serverではデータベースの動的な追加がサポートされているため、ディレクトリ全体を使用できない状態にすることなく、新しいデータベースを必要に応じて追加できます。

10.2.2 分散のためのDirectory Proxy Serverの使用

Directory Proxy Serverでは、ディレクトリ情報を複数のサーバーに分割しますが、データの階層を変更する必要はありません。データ分散の重要な側面は、データ・セットを論理的に分割できることです。ただし、あるクライアント・アプリケーションで機能する分散ロジックは、別のクライアント・アプリケーションで機能しないことがあります。

このため、Directory Proxy Serverを使用して、データの分散方法およびディレクトリ・リクエストのルーティング方法を指定できます。たとえば、LDAP操作は、ディレクトリ情報ツリー(DIT)階層に基づいて様々なディレクトリ・サーバーにルーティングできます。操作は、操作タイプまたはカスタム分散アルゴリズムに基づいてルーティングすることもできます。

Directory Proxy Serverによって、事実上、分散の詳細がクライアント・アプリケーションから隠されます。クライアントの観点から、単一ディレクトリでディレクトリ問合せに対応します。クライアント・リクエストは、特定の分散方法に従って分散されます。次の各項で説明するように、異なるルーティング方針をDITの異なる部分に関連付けることができます。

10.2.2.1 DITに基づくルーティング

この方針は、ディレクトリ・エントリをDIT構造に基づいて分散するために使用できます。たとえば、サブツリーo=sales,dc=example,dc=comのエントリをDirectory Server Aにルーティングし、サブツリーo=hr,dc=example,dc=comのエントリをDirectory Server Bにルーティングできます。

10.2.2.2 カスタム・アルゴリズムに基づくルーティング

場合によっては、DIT構造を使用することなく、エントリを複数のディレクトリ・サーバーに分散する必要があります。たとえば、サブスクライバを表すエントリをou=subscribers,dc=example,dc=comに格納するサービス・プロバイダを考えます。サブスクライバの数が増加すると、サブスクライバをサブスクライバIDの範囲に基づいて複数のサーバーに分散することが必要になる場合があります。カスタム・ルーティング・アルゴリズムでは、範囲が1-10000のIDを持つサブスクライバ・エントリをDirectory Server Aに配置し、範囲が10001-無限のIDを持つサブスクライバ・エントリをDirectory Server Bに配置できます。サーバーBのデータが大きすぎる場合は、2000から始まるIDを持つエントリを新しいサーバーServer Cに配置できるように分散アルゴリズムを変更できます。

Directory Proxy ServerのDistributionAlgorithmインタフェースを使用して、独自のルーティング・アルゴリズムを実装できます。

10.2.3 Directory Proxy Serverを使用したバインドDNに基づくリクエストの分散

このシナリオでは、企業は顧客データを地理的な場所に基づいて3つのマスター・サーバーに分散します。イギリスを本拠地としている顧客は、データをロンドンのマスター・サーバーに格納しています。フランスの顧客は、データをパリのマスター・サーバーに格納しています。日本の顧客のデータは、東京のマスター・サーバーに格納されています。顧客は、独自のデータを単一のWebベースのインタフェースで更新できます。

ユーザーは、Webベースのアプリケーションを使用して、データベースの独自の情報を更新できます。認証フェーズでは、ユーザーは電子メールアドレスを入力します。イギリスの顧客の電子メール・アドレスは、*@uk.example.comという形式です。フランスの顧客の場合、電子メール・アドレスの形式は*@fr.example.com、日本の顧客の場合は*@ja.example.comです。Directory Proxy Serverは、LDAP対応のクライアント・アプリケーションを介してこれらのリクエストを受信します。その後、Directory Proxy Serverは、認証時に入力された電子メール・アドレスに基づいて、リクエストを適切なマスター・サーバーにルーティングします。

このシナリオを次の図に示します。

図10-9 Directory Proxy Serverを使用したバインドDNに基づくリクエストのルーティング

「図10-9 Directory Proxy Serverを使用したバインドDNに基づくリクエストのルーティング」の説明

10.3 DITの下位へのデータ分散

多くの場合、DITの最上位では、データ分散は必要ありません。ただし、ツリーの分散された部分のエントリでは、ツリーの上位のエントリが必要になることがあります。この項では、この場合の分散方針をどのように設計するかを示すサンプル・シナリオについて説明します。

10.3.1 分散データの論理ビュー

Example.comには、グループ用の1つのサブツリーおよびユーザー用の別のサブツリーがあります。グループ定義の数は小さく、非常に静的ですが、ユーザー・エントリの数は大きく、拡大し続けます。したがって、Example.comでは、ユーザー・エントリのみを3つのサーバーに分散する必要があります。ただし、グループ定義、そのACI、およびネーミング・コンテキストの最上位にあるACIは、ユーザー・サブツリーの下のエントリすべてにアクセスする必要があります。

次の図は、データ分散要件の論理ビューを示しています。

図10-10 分散データの論理ビュー

「図10-10 分散データの論理ビュー」の説明

10.3.2 データ記憶域の物理ビュー

ou=peopleサブツリーは、各エントリのsn属性の先頭文字に従って3つのサーバーに分割されています。ネーミング・コンテキスト(dc=example,dc=com)およびou=groupsコンテナは、各サーバーの1つのデータベースに格納されています。このデータベースは、ou=peopleの下のエントリにアクセスできます。ou=peopleコンテナは、その独自のデータベースに格納されています。

次の図は、個々のDirectory Serverにおけるデータの格納方法を示しています。

図10-11 データ記憶域の物理ビュー

「図10-11 データ記憶域の物理ビュー」の説明

ou=peopleコンテナは、最上位コンテナの接尾辞ではありません。

10.3.3 サンプル分散シナリオのDirectory Server構成

前述した各サーバーは、分散チャンクと考えられます。ネーミング・コンテキストおよびou=groupsの下のエントリを含む接尾辞は、各チャンクで同じです。したがって、マルチマスター・レプリケーション承諾は、この接尾辞に対して、3つの各チャンクをまたいで設定されます。

可用性を確保するために、各チャンクもレプリケートされます。したがって、チャンクごとに少なくとも2つのマスター・レプリカが定義されています。

次の図は、チャンクごとに3つのレプリカが定義されたDirectory Server構成を示しています。わかりやすくするために、レプリケーション承諾は1つのチャンクについてのみ示されていますが、他の2つのチャンクでも同じです。

図10-12 Directory Server構成

「図10-12 Directory Server構成」の説明

10.3.4 サンプル分散シナリオのDirectory Proxy Server構成

Directory Proxy Serverを使用したディレクトリ・データへのクライアント・アクセスは、データ・ビューで提供されます。データ・ビューの詳細は、Oracle Directory Server Enterprise Editionリファレンスの第17章「Directory Proxy Serverの配布」を参照してください。

このシナリオでは、分散された接尾辞ごとに1つのデータ・ビューが必要であり、ネーミング・コンテキスト(dc=example,dc=com)およびou=groupsサブツリーに1つのデータ・ビューが必要です。

次の図は、分散データへのアクセスを提供するDirectory Proxy Serverデータ・ビューの構成を示しています。

図10-13 Directory Proxy Server構成

「図10-13 Directory Proxy Server構成」の説明

10.3.5 データ増大の考慮事項

分散データは、分散アルゴリズムに従って分割されます。使用する分散アルゴリズムを決定する場合は、データの量が変化する可能性があること、および分散方針は拡張可能である必要があることに留意してください。データの完全な再分散を必要とするアルゴリズムは使用しないでください。

たとえば、uidに基づく数値配布アルゴリズムは、容易に拡張できます。最初にuid=0-999およびuid=1000-1999という2つのデータ・セグメントを設定すると、後の段階で、uid=2000-2999という3つ目のセグメントを容易に追加できます。

10.4 分散のためのリフェラルの使用

リフェラルはサーバーによって返される情報であり、操作リクエストを続行するために接続するサーバーをクライアント・アプリケーションに通知します。Directory Proxy Serverを使用して分散ロジックを管理しない場合は、分散データ間の関係を別の方法で定義する必要があります。関係を定義する1つの方法として、リフェラルを使用する方法があります。

Directory Serverでは、リフェラルをいつどのように返すかを構成する方法が3つサポートされています。

- デフォルトのリフェラル。サーバーに一致する接尾辞がないDNをクライアント・アプリケーションが示した場合、ディレクトリはデフォルトのリフェラルを返します。

- 接尾辞リフェラル。メンテナンス時またはセキュリティ上の理由で接尾辞全体がオフラインになっている場合、サーバーはその接尾辞で定義されているリフェラルを返します。クライアントが書込み操作をリクエストした場合、接尾辞の読取り専用レプリカもマスター・サーバーへのリフェラルを返します。

- スマート・リフェラル。これらのリフェラルは、ディレクトリ内のエントリに格納されます。スマート・リフェラルは、DNがスマート・リフェラルを含むエントリのDNに一致するサブツリーを把握しているDirectory Serverを指します。

次の図は、リフェラルを使用して、イギリスのクライアントをグローバル・トポロジ内の適切なサーバーに誘導する方法を示しています。このシナリオでは、クライアント・アプリケーションがリフェラルに従うには、トポロジ内のすべてのサーバーに(TCP/IPレベルで)接続できる必要があります。

図10-14 リフェラルを使用した特定サーバーへのクライアントの誘導

「図10-14 リフェラルを使用した特定サーバーへのクライアントの誘導」の説明

10.4.1 リフェラルを使用したDirectory Proxy Serverの使用

Directory Proxy Serverをリフェラル・メカニズムと組み合せて使用することで、同じ結果を得ることができます。このようにDirectory Proxy Serverを使用する利点は、クライアント・アプリケーションの負荷および複雑さが減少することです。クライアント・アプリケーションは、Directory Proxy ServerのURLのみを認識します。分散ロジックがなんらかの理由で変更される場合、この変更はクライアント・アプリケーションに対して透過的に行われます。

次の図は、前に説明したシナリオをDirectory Proxy Serverの使用により簡略化する方法を示しています。クライアント・アプリケーションは、リフェラルを処理するProxy Serverに常に接続します。

図10-15 リフェラルを使用したDirectory Proxy Serverの使用

「図10-15 リフェラルを使用したDirectory Proxy Serverの使用」の説明

11 グローバル・デプロイメントの設計

グローバル・デプロイメントでは、複数の地理的な場所またはデータ・センターにあるディレクトリ・サービスへのアクセスが必要になります。この章では、複数のデータ・センターにDirectory Server Enterprise Editionを効果的にデプロイするための方針について説明します。これらの方針によって、第5章「サービス・レベル合意の定義」で特定したサービス品質要件に反しないことが確実になります。

この章の内容は、次のとおりです。

- 複数のデータ・センターをまたぐレプリケーションの使用

- グローバル・デプロイメントでのDirectory Proxy Serverの使用

11.1 複数のデータ・センターをまたぐレプリケーションの使用

レプリケーションの目標の1つは、LDAPサービスを地理的に分散できるようにすることです。レプリケーションを使用すると、複数のサーバーや複数のデータ・センターに、まったく同じ情報のコピーを保持できます。レプリケーションの概要は、このガイドの第10章「スケーラビリティを持つデプロイメントの設計」およびOracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。

Directory Serverは、異なるプラットフォームで稼働するインスタンス間のレプリケーションをサポートしています。

この項の内容は次のとおりです。

- マルチマスター・レプリケーション

- カスケード型レプリケーション

- 優先順位付きレプリケーション

- 部分レプリケーション

- 国際的な企業のレプリケーション方針の例

11.1.1 マルチマスター・レプリケーション

マルチマスター・レプリケーションでは、同じデータのレプリカが複数のサーバーに存在します。マルチマスター・レプリケーションの詳細は、次の項を参照してください。

- マルチマスター・レプリケーションの概要

- WAN経由のマルチマスター・レプリケーション

- フル・メッシュのマルチマスター・トポロジ

11.1.1.1 マルチマスター・レプリケーションの概要

マルチマスター構成では、複数のマスターでデータが更新されます。各マスターでは変更ログを保守し、各マスターに加えられた変更は、他のサーバーにレプリケートされます。各マスターは、サプライヤおよびコンシューマの役割を果たします。

マルチマスター構成には、次の利点があります。

- 1つのマスターにアクセスできない場合は、自動書込みフェイルオーバーが行われます。

- 地理的に分散した環境内のローカル・マスターで更新が行われます。

マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルを使用します。これは同一エントリを別々のサーバーで同時に変更できることを意味します。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。レプリケーションの競合が発生する可能性は、待機時間など、WANの様々な属性によって高くなります。通常、競合解消は自動的に行われます。優先される変更は、数多くの競合ルールによって判断されます。場合によっては、競合を手動で解決する必要があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の一般的なレプリケーションの競合の解決に関する説明を参照してください。

マルチマスター・トポロジでサポートされるマスターの数は、理論的には無制限です。コンシューマおよびハブの数も、理論的には無制限です。ただし、1つのサプライヤがレプリケートできるコンシューマの数は、サプライヤ・サーバーの容量によって異なります。SLAMD分散負荷生成エンジン(SLAMD)を使用すると、サプライヤ・サーバーの容量を評価できます。SLAMDの詳細およびSLAMDソフトウェアのダウンロード方法は、http://www.slamd.com (http://www.slamd.com/)を参照してください。

マルチマスター環境内の各サプライヤには、レプリケーション承諾が必要です。次の図は、2つのマスター・サーバーと、そのサーバーのレプリケーション承諾を示しています。

図11-1 マルチマスター・レプリケーション構成(2つのマスター)

「図11-1 マルチマスター・レプリケーション構成(2つのマスター)」の説明

前の図では、マスターAおよびマスターBが同じデータのマスター・レプリカを保持しています。各マスターは、レプリケーションのフローを指定するレプリケーション承諾を保持しています。マスターAは、レプリケーション承諾1の範囲ではマスターとして機能し、レプリケーション承諾2の範囲ではコンシューマとして機能します。

マルチマスター・レプリケーションは、次のタスクに使用できます。

- レプリカIDの使用による更新のレプリケート
異なるレプリカIDから更新が発生した場合は、レプリカIDを使用して更新を行うことで、複数のサプライヤからコンシューマを同時に更新できます。

- レプリケーション承諾の有効化または無効化
レプリケーション承諾は、構成後、無効のままにしておき、必要になったときに短時間で有効化できます。この機能により、レプリケーションを柔軟に構成できます。これは、複数のマスターを使用しているかどうかに関係なく実行できます。

11.1.1.2 WAN経由のマルチマスター・レプリケーション

Directory Serverは、WAN経由のマルチマスター・レプリケーションをサポートしています。この機能により、国際的な、複数のデータ・センター・デプロイメントにおける、地理的な境界をまたぐマルチマスター・レプリケーション構成を実現できます。

通常、「初期レプリケーション要件の評価」で計算されるNumber of hostsが16未満、または大幅に超過しない場合は、トポロジに、完全に接続されたトポロジ内のマスター・サーバーのみが含まれている、つまり、すべてのマスターがトポロジ内の他のすべてのマスターにレプリケートする状態である必要があります。WAN経由のマルチマスター・レプリケーション構成では、WANで分離されたすべてのDirectory Serverインスタンスが、Directory Server 5.2よりも前のバージョンを実行していないようにしてください。マスターが4つを超えるマルチマスター・トポロジには、Directory Server 6.xが必要となります。

レプリケーション・プロトコルでは、完全な非同期サポート以外に、ウィンドウ、グループ化および圧縮のメカニズムが提供されます。これらの機能によって、WAN経由のマルチマスター・レプリケーションが実行可能になります。レプリケーション・データの転送レートは、使用可能な物理媒体が帯域幅に関して許可している転送レートを常に下回ります。レプリカ間の更新が有効帯域幅と物理的に見合わないほどの量である場合、更新負荷が大きくなったときにレプリカ間に差異が発生することを、チューニングによって回避できなくなります。レプリケーションの遅延と更新のパフォーマンスは、変更率、エントリ・サイズ、サーバー・ハードウェア、平均待機時間および平均帯域幅を含む、様々な要素によって異なります。

レプリケーション・メカニズムの内部パラメータは、デフォルトでWAN用に最適化されています。ただし、前述の要素などが原因でレプリケーションが遅くなる場合は、ウィンドウ・サイズとグループ・サイズのパラメータを実験的に調節してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な使用率を高めることもできます。さらに、Directory Serverでは、帯域幅の使用率を最適化するためにレプリケーション・データ圧縮をサポートしています。

WANリンク経由でデータをレプリケートする場合は、データの整合性と機密性を保証するなんらかの形式のセキュリティを導入することをお薦めします。Directory Serverで使用できるセキュリティ手段の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第5章「Directory Serverのセキュリティ」を参照してください。

11.1.1.2.1 グループとウィンドウのメカニズム

Directory Serverは、レプリケーションのフローを最適化するためのグループとウィンドウのメカニズムを提供しています。グループのメカニズムを使用すると、変更を個別にではなく、まとめて送信するように指定できます。グループ・サイズは、1つの更新メッセージにバンドルできるデータ変更の最大数を表します。ネットワーク接続がレプリケーションのボトルネックになっているように見える場合は、グループ・サイズを大きくし、レプリケーションのパフォーマンスを再度チェックしてください。グループ・サイズを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のグループ・サイズの構成に関する説明を参照してください。

サプライヤが処理を継続する前にコンシューマからの確認応答を待つことなく、特定の数の更新リクエストがコンシューマに送信されることが、ウィンドウのメカニズムによって指定されます。ウィンドウ・サイズは、コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、すばやく連続して数多くのメッセージを送信すると、より効率的です。適切なウィンドウ・サイズを使用することにより、レプリカがレプリケーション更新または確認応答の着信を待つ間に費やす時間を削減できます。コンシューマ・レプリカがサプライヤに遅れをとっている場合、さらに調整を行う前にウィンドウ・サイズをデフォルトよりも高い値(100など)に設定して、レプリケーション・パフォーマンスを再度チェックします。レプリケーションの更新頻度が高く、そのために更新間隔が短い場合は、LAN接続のレプリカでも、ウィンドウ・サイズを大きくするとパフォーマンスが向上する可能性があります。ウィンドウ・サイズを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のウィンドウ・サイズの構成に関する説明を参照してください。

グループとウィンドウのメカニズムは、いずれも変更のサイズに基づいています。このため、変更のサイズが大幅に変動する場合は、これらのメカニズムを使用してレプリケーションのパフォーマンスを最適化することが現実的でない場合があります。変更のサイズが比較的安定している場合は、グループとウィンドウのメカニズムを使用して、増分更新と合計更新を最適化できます。

11.1.1.2.2 レプリケーション圧縮

SolarisおよびLinuxのプラットフォームでは、グループ化とウィンドウのメカニズム以外に、レプリケーション圧縮も構成できます。レプリケーション圧縮によって、レプリケーションのフローが効率化され、これにより、WANを経由するレプリケーションでのボトルネックの発生率が大幅に低下します。レプリケートされるデータを圧縮すると、CPU性能は十分でも帯域幅が狭いネットワークの場合や、バルク変更をレプリケートする場合など、特定の状況におけるレプリケーションのパフォーマンスを改善できます。また、大きいエントリが含まれるリモート・レプリカを初期化する場合も、レプリケーション圧縮が有益であることがあります。ネットワーク帯域幅が広いLocal Area Network (LAN)ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算により、レプリケーションが遅くなります。

レプリケーション・メカニズムでは、Zlib圧縮ライブラリが使用されます。予想されるレプリケーション使用率に対して、WAN環境で最高の結果が得られる圧縮レベルを実験的にテストし、選択する必要があります。

レプリケーション圧縮を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリケーション圧縮の構成に関する説明を参照してください。

11.1.1.3 フル・メッシュのマルチマスター・トポロジ

フル・メッシュのマルチマスター・トポロジでは、各マスターが、他のマスターのそれぞれと接続しています。フル・メッシュのトポロジでは高可用性が実現され、データの整合性が保証されます。次の図は、いくつかのコンシューマを含む、フル・メッシュの4方向マルチマスター・レプリケーション・トポロジを示しています。

図11-2 フル・メッシュの4方向マルチマスター・レプリケーション構成

「図11-2 フル・メッシュの4方向マルチマスター・レプリケーション構成」の説明

図11-2では、変更リクエストに常に対応できるようにするために、4つのマスターに対する接尾辞が保持されています。各マスターでは独自の変更ログを保守します。いずれかのマスターによってクライアントからの変更リクエストが処理されると、その操作がその変更ログに記録されます。次に、そのマスターによって他のマスターにレプリケーションの更新が送信され、その結果、他のコンシューマに送信されます。また、各マスターには、レプリケーション・マネージャ・エントリも格納され、レプリケーションの更新の送信に備えてバインドするとき、このエントリを使用して他のマスターを認証します。

各コンシューマには、レプリケーション・マネージャ・エントリに対応する、1つ以上のエントリが格納されます。コンシューマは、このエントリを使用して、レプリケーションの更新を送信するためにバインドするときにマスターを認証します。各コンシューマでは、レプリケーション・マネージャ・エントリを1つのみ保持でき、このエントリを使用すると、すべてのマスターが、同じレプリケーション・マネージャ・エントリを使用して認証できるようになります。デフォルトでは、コンシューマには、トポロジ内のすべてのマスターに関するリフェラルが設定されています。コンシューマは、クライアントから変更リクエストを受信すると、クライアントにリフェラルを返信します。リフェラルの詳細は、Oracle Directory Server Enterprise Editionリファレンスのリフェラルとレプリケーションに関する説明を参照してください。

図11-3は、マスターAに設定が必要なレプリケーション承諾、変更ログおよびレプリケーション・マネージャ・エントリを詳細に示しています。図11-4は、コンシューマEに関して同じ内容を詳細に示しています。

図11-3 マスターAのレプリケーション構成(フル・メッシュのトポロジ)

「図11-3 マスターAのレプリケーション構成(フル・メッシュのトポロジ)」の説明

図11-4 コンシューマ・サーバーEのレプリケーション構成(フル・メッシュのトポロジ)

「図11-4 コンシューマ・サーバーEのレプリケーション構成(フル・メッシュのトポロジ)」の説明

マスターAには次のものが必要です。

- マスター・レプリカ

- 変更ログ

- マスターB、CおよびDのレプリケーション・マネージャ・エントリ(各レプリカで同じレプリケーション・マネージャ・エントリを使用しない場合)

- マスターB、C、DおよびコンシューマEとFのレプリケーション承諾

コンシューマEには次のものが必要です。

- コンシューマ・レプリカ

- レプリケーションの更新を送信するためにバインドするとき、マスターAとBを認証するためのレプリケーション・マネージャ・エントリ

11.1.2 カスケード型レプリケーション

カスケード型レプリケーション構成では、ハブとして機能するサーバーが、サプライヤとして機能するサーバーから更新を受信します。ハブは、それらの更新をコンシューマにリプレイします。次の図は、カスケード型レプリケーション構成を示しています。

図11-5 カスケード型レプリケーション構成

「図11-5 カスケード型レプリケーション構成」の説明

カスケード型レプリケーションは、次の場合に役立ちます。

- コンシューマの数が多い場合
レプリケーション・トポロジ内のマスターは更新トラフィックをすべて処理するため、コンシューマへのレプリケーション・トラフィックをサポートすると、マスターに大きな負荷がかかる場合があります。レプリケーション・トラフィックの負荷を複数のハブに分散すると、それぞれのハブから、コンシューマのサブセットに対して、レプリケーションの更新を送信できます。

- 地理的に分散した環境で、ローカル・ハブを使用して接続コストを削減する場合

次の図は、数多くのコンシューマに対するカスケード型レプリケーションを示しています。

図11-6 数多くのコンシューマに対するカスケード型レプリケーション

「図11-6 数多くのコンシューマに対するカスケード型レプリケーション」の説明

図11-6では、ハブ1およびハブ2がレプリケーションの更新をコンシューマの1から10に中継し、ディレクトリの更新を処理するリソースをマスター・レプリカに多く確保しています。

マスターとハブは、変更ログを保持しています。ただし、クライアントからのディレクトリ変更リクエストは、マスターによってのみ処理できます。ハブには、更新をハブに送信するマスターごとに、レプリケーション・マネージャ・エントリが格納されています。コンシューマの1から10には、ハブ1およびハブ2のレプリケーション・マネージャ・エントリが格納されています。

コンシューマおよびハブは、クライアントから受信した検索リクエストを処理できますが、変更リクエストは処理できません。コンシューマとハブは変更リクエストをマスターに委任します。

11.1.3 優先順位付きレプリケーション

優先順位付きレプリケーションは、特定の属性に関してレプリケートされるデータについて、より厳密な一貫性を強く求めるビジネス要件がある場合に使用できます。前のバージョンのDirectory Serverの場合は、受信した順序で更新がレプリケートされました。優先順位付きレプリケーションを使用すると、トポロジ内の他のサーバーにレプリケートするとき、特定の属性に対する更新が優先されるように指定できます。

優先順位はブール型の機能であるため、オンまたはオフを選択します。優先順位にレベルはありません。レプリケートを待機している更新が格納されたキューでは、優先順位がオンの更新がレプリケートされた後、優先順位がオフの更新がレプリケートされます。

優先順位のルールは、次のレプリケーション優先順位ルールのプロパティを使用して構成します。

- クライアントのアイデンティティ、bind-dn

- 更新のタイプ、op-tyupe

- 更新されたエントリまたはサブツリー、base-dn

- 更新によって変更された属性、att

これらのプロパティの詳細は、repl-priorityを参照してください。

マスターが1つ以上のハブまたはコンシューマ・レプリカに更新をレプリケートするとき、その更新の優先順位は、すべてのハブおよびコンシューマ・レプリカで等しくなります。優先順位付きレプリケーションの優先順位ルールで、パラメータが1つ構成されている場合は、そのパラメータに一致するすべての更新に対して、レプリケーションの優先順位が付けられます。優先順位付きレプリケーションの優先順位ルールで、パラメータが2つ以上構成されている場合は、すべてのパラメータに一致するすべての更新に対して、レプリケーションの優先順位が付けられます。

次の例では、マスター・レプリカがエントリに対する更新のレプリケートを試みた後、エントリの追加がレプリケートされる可能性があります。

- マスター・レプリカにエントリを追加した後、マスター・レプリカ上で更新します。

- 更新操作にはレプリケーションの優先順位を設定しているものの、追加操作には設定していません。

この例では、追加操作がレプリケートされるまで、更新操作をレプリケートできません。追加操作の後、更新は、時系列の順番に従って、レプリケートされることを待機します。

優先順位付きレプリケーションには、次の利点があります。

- セキュリティの向上。優先順位付きレプリケーションは、アカウントのロックアウトのためにデフォルトで使用されます。たとえば、ある従業員が組織を離れたため、その従業員のアカウントをロックする場合を考えます。その従業員が、アカウントのロックアウトがまだレプリケートされていないリモート・サーバーにログインできないように、アカウントのロックアウトの変更は、他の変更がレプリケートされる前にレプリケートされます。

- 一貫性の向上。Directory Serverのレプリケーションは、一貫性に関して厳密ではありません。優先順位付きレプリケーションを使用すると、組織内で重要とみなされる特定の属性に対して、より強力な一貫性を保証できます。

11.1.4 部分レプリケーション

グローバルなトポロジ(複数の国にデータ・センターがある)では、セキュリティまたは法令順守の理由から、レプリケーションの制限が必要になる場合があります。たとえば、法的な規制により、特定の従業員情報を米国国外にコピーできないと規定されている場合があります。あるいは、オーストラリアのサイトでは、オーストラリアの従業員の詳細情報のみが必要になる可能性があります。

部分レプリケーション機能を使用すると、エントリ内にある属性のサブセットのみをレプリケートできます。レプリケートできる属性がどれで、できない属性がどれかを指定するには、属性リストを使用します。部分レプリケーションは、読取り専用のコンシューマに対してのみ適用できます。

部分レプリケーションは、ある接尾辞またはサブ接尾辞の、すべてのエントリの属性のサブセットをレプリケートする場合に使用できます。部分レプリケーションを承諾単位で構成すると、属性をレプリケーションの対象にしたり、レプリケーションから属性を除外できます。通常、部分レプリケーションは、属性を除外するように構成されています。機能と属性間には相互依存性があるため、対象とする属性のリストを管理することは困難です。

部分レプリケーションは、次の目的に使用できます。

- イントラネットとエクストラネットのサーバー間で同期する内容のフィルタ

- デプロイメントで場所を問わずに利用できる属性を特定の属性に限定する必要がある場合の、レプリケーション・コストの削減

部分レプリケーションは、レプリケーション承諾プロパティのrepl-fractional-include-attr属性およびrepl-fractional-exclude-attr属性を使用して構成します。これらのプロパティの詳細は、repl-agmtを参照してください。部分レプリケーションを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の部分レプリケーションに関する説明を参照してください。

11.1.5 国際的な企業のレプリケーション方針の例

この例では、ある企業の2つの主要なデータ・センターがロンドンとニューヨークに1つずつあり、WANで隔てられています。ここでは、通常の業務時間内は、ネットワークが非常にビジーであることを前提にします。

この例では、Number of hostsを8と計算しています。2つのデータ・センターのそれぞれには、完全に接続された、4方向のマルチマスター・トポロジが配置されています。また、これらの2つのトポロジも、互いに完全接続されています。わかりやすくするため、次の図には、2つのデータ・センター間のレプリケーション承諾が一部のみ示されています。

この例のレプリケーション方針には、次の内容が含まれています。

- ディレクトリ・データのマスター・コピーは、両データ・センターのサーバーで保持します。

- デプロイメントをまたぐ高可用性および書込みフェイルオーバーを実現するために、データ・センター間にマルチマスター・レプリケーション・トポロジを配置します。

- 帯域幅を最適化するために、WANリンク全体をまたぐレプリケーションは、ピークを外れた時間帯にのみ実行されるようにスケジュールします。

- パフォーマンス向上のために、クライアント・アプリケーションをローカル・サーバーに振り分けます。米国のクライアントは、ニューヨークのデータ・センター内のマスターからの読取りと、これらのマスターへの書込みを実行します。イギリスのクライアントは、ロンドンのデータ・センター内のマスターからの読取りと、これらのマスターへの書込みを実行します。

図11-7 2つのデータ・センターでのロード・バランシングのためのマルチマスター・レプリケーションの使用

「図11-7 2つのデータ・センターでのロード・バランシングのためのマルチマスター・レプリケーションの使用」の説明

11.2 グローバル・デプロイメントでのDirectory Proxy Serverの使用

グローバル企業では、集中管理データ・モデルにより、スケーラビリティとパフォーマンスの問題が発生する可能性があります。このような状況でDirectory Proxy Serverを使用すると、データを効率的に分散し、検索や更新のリクエストを適切にルーティングできます。

11.2.1 グローバル企業の分散方針の例

ここで示すアーキテクチャでは、大手金融機関の本社がロンドンにあります。この組織は、ロンドン、ニューヨークおよび香港にデータ・センターを保有しています。現在、従業員が利用できるデータの大部分は、ロンドンにある古いRDBMSリポジトリにまとめて格納されています。この金融機関のクライアント・コミュニティからは、完全にWAN経由でこのデータにアクセスしています。

この集中管理モデルでスケーラビリティとパフォーマンスの問題が発生しているため、この組織では、分散データ・モデルに移行することを決定しています。また、同時に、LDAPディレクトリ・インフラストラクチャを配置することも決定しました。問題のデータはミッション・クリティカルであるとみなされているため、可用性の高い、フォルト・トレラントなインフラストラクチャにデプロイする必要があります。

クライアント・アプリケーションのプロファイル分析から、データが顧客ベースのものであることがわかっています。そのため、地域のクライアント・コミュニティからアクセスされるデータの95パーセントは、そのコミュニティに固有のデータです。まれに、アジアのクライアントが北米の顧客のデータにアクセスすることもありますが、このことはほとんど発生しません。また、クライアント・コミュニティでは、ときどき顧客情報を更新することも必要となります。

次の図は、分散ソリューションの論理アーキテクチャを示しています。

図11-8 分散ディレクトリ・インフラストラクチャ

「図11-8 分散ディレクトリ・インフラストラクチャ」の説明

95パーセントがローカル・データへのアクセスというプロファイル結果を受けて、この組織は、ディレクトリ・インフラストラクチャを地理的に分散することにしました。香港、ニューヨークおよびロンドンというそれぞれの地理的な場所に、複数のディレクトリ・コンシューマが配置されます。わかりやすくするため、この図でロンドンのコンシューマは省略されています。これらの各コンシューマは、拠点固有の顧客データを保持するように構成されます。ヨーロッパと中東の顧客のデータは、ロンドンのコンシューマが保持します。北米と南米の顧客のデータは、ニューヨークのコンシューマが保持します。アジアと環太平洋地域の顧客のデータは、香港のコンシューマが保持します。

このデプロイメントでは、クライアント・コミュニティのデータ・リクエストのほとんどが、ローカルのコミュニティに対して行われます。この方針によって、集中管理モデルを大幅に上回るパフォーマンスが実現されます。クライアント・リクエストはローカルに処理されるため、ネットワークのオーバーヘッドが減少します。ローカルのディレクトリ・サーバーによって、ディレクトリ・インフラストラクチャが効果的にパーティション化されるため、ディレクトリ・サーバーのパフォーマンスとスケーラビリティが向上します。コンシューマ・ディレクトリ・サーバーの各セットは、クライアントが更新リクエストを送信した場合はリフェラルを返すように構成されます。また、どこか別の場所に格納されているデータの検索リクエストをクライアントが送信した場合にも、リフェラルが返されます。

クライアントのLDAPリクエストは、ハードウェア・ロード・バランサを介してDirectory Proxy Serverに送信されます。このハードウェア・ロード・バランサによって、クライアントが、常に1つ以上のDirectory Proxy Serverにアクセスできることが保証されます。ローカルに配置されたDirectory Proxy Serverでは、最初に、ローカルの顧客データを保持する複数のローカル・ディレクトリ・サーバーのアレイにすべてのリクエストをルーティングします。Directory Proxy Serverのインスタンスは、複数のディレクトリ・サーバーのアレイ全体にロード・バランスするように構成されます。このロード・バランシングにより、自動フェイルオーバーおよびフェイルバックが実現されます。

ローカルの顧客情報に対するクライアントの検索リクエストは、ローカル・ディレクトリによって満たされます。クライアントには、Directory Proxy Serverを介して適切なレスポンスが返されます。地理的に外部にある顧客情報に対するクライアントの検索リクエストは、最初に、Directory Proxy Serverにリフェラルを返すことで、ローカルのディレクトリ・サーバーによって満たされます。

このリフェラルには、地理的な分散に対応するDirectory Proxy Serverインスタンスを指すLDAP URLが含まれています。ローカルのDirectory Proxy Serverは、ローカル・クライアントのかわりに、このリフェラルを処理します。ローカルのDirectory Proxy Serverは、次に、この検索リクエストをDirectory Proxy Serverの適切な分散インスタンスに送信します。分散Directory Proxy Serverは、この検索リクエストを分散Directory Serverに転送し、適切なレスポンスを受信します。次に、このレスポンスは、Directory Proxy Serverの分散インスタンスおよびローカル・インスタンスを介して、ローカル・クライアントに返されます。

ローカルのDirectory Proxy Serverが受信した更新リクエストは、最初に、ローカルのDirectory Serverが返すリフェラルによって満たされます。Directory Proxy Serverは、ローカル・クライアントのかわりに、このリフェラルに従います。ただし、この場合、この更新リクエストは、プロキシによって、ロンドンに配置されているサプライヤ・ディレクトリ・サーバーに転送されます。サプライヤのDirectory Serverは、この更新をサプライヤ・データベースに適用し、そのレスポンスをローカルのDirectory Proxy Serverを介してローカル・クライアントに返します。その後、サプライヤのDirectory Serverは、この更新を適切なコンシューマのDirectory Serverに伝播します。

12 高可用性デプロイメントの設計

高可用性とは、ディレクトリ・サービスに関して合意された、最小の稼働時間およびパフォーマンス・レベルを意味します。合意されたサービス・レベルは、組織ごとに異なります。サービス・レベルは、システムがアクセスされる時刻、システムをメンテナンスのために停止できるかどうか、組織にとっての停止時間のコストなどの要素によって異なる場合があります。このコンテキストでは、障害とは、ディレクトリ・サービスがこの最低レベルのサービスを提供することを妨げるものとして定義されます。

この章の内容は、次のとおりです。

- 可用性とシングル・ポイント障害

- 高可用性のためのレプリケーションおよび冗長性の使用

12.1 可用性とシングル・ポイント障害

高可用性を実現するDirectory Server Enterprise Editionデプロイメントは、障害から迅速にリカバリできます。高可用性デプロイメントでは、コンポーネント障害が個々のディレクトリ問合せに影響することがありますが、完全なシステム障害は発生しません。シングル・ポイント障害(SPOF)とは、障害が発生すると、システム全体が使用できなくなるか、またはシステム全体の信頼性が低下する原因となる、1つのシステム・コンポーネントのことです。高可用性デプロイメントを設計する場合は、潜在的なSPOFを識別し、これらのSPOFをどのように軽減できるかを調べます。

SPOFは、次の3つのカテゴリに分けることができます。

- ハードウェア障害(サーバー・クラッシュ、ネットワーク障害、停電、ディスク・ドライブ・クラッシュなど)

- ソフトウェア障害(Directory ServerのクラッシュやDirectory Proxy Serverのクラッシュなど)

- データベースの破損

12.1.1 SPOFの軽減

冗長性を使用することによって、1つのコンポーネントの障害が原因でディレクトリ・サービス全体が失敗しないようにすることができます。冗長性により、冗長なソフトウェア・コンポーネント、ハードウェア・コンポーネントまたは両方が提供されます。この方針の例として、Directory Serverの複数のレプリケートされたインスタンスを別々のホストにデプロイしたり、Directory ServerデータベースのストレージにRedundant Array of Independent Disks (RAID)を使用することをあげることができます。レプリケートされたDirectory Serverによる冗長性は、高可用性を実現する最も効率的な方法です。

12.1.1.1 冗長性の長所と短所

高可用性ディレクトリ・サービスを提供するためのより一般的なアプローチは、冗長なサーバー・コンポーネントとレプリケーションの使用です。冗長ソリューションは、通常はコストが低く、実装と管理が容易です。冗長ソリューションの一部としてのレプリケーションには、可用性以外に多くの機能があります。レプリケーションの主な長所は、読取り負荷を複数のサーバーに分散できることですが、これにより、サーバー管理の面でオーバーヘッドが増加します。また、レプリケーションにより、特定の制限内で読取り操作のスケーラビリティ、および設計が適切である場合には書込み操作のスケーラビリティが提供されます。レプリケーション概念の概要は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。

障害が発生している間、冗長システムの可用性が低下することがあります。たとえば、負荷が2つの冗長サーバー・コンポーネントで共有されている環境を考えます。1つのサーバー・コンポーネントで障害が発生すると、もう一方のサーバーの負荷が過剰になり、このサーバーでクライアント・リクエストへの応答が遅くなる可能性があります。レスポンスが遅いと、迅速なレスポンス時間に依存するクライアントでは障害とみなされることがあります。つまり、サービスが動作可能であっても、サービスの可用性がクライアントの可用性要件を満たさない場合があります。

12.1.1.2 冗長性によるSPOFの処理方法

この章の最初に説明したSPOFに関しては、冗長性により、次の方法で障害が処理されます。

- 単一のハードウェア障害。ハードウェア障害は、単一であっても、マシンにとって致命的です。したがって、冗長ハードウェアがある場合でも、障害を修復するために手動操作が必要になります。

- Directory ServerまたはDirectory Proxy Serverの障害。サーバーは自動的に再起動されます。

- データベースの破損。アーキテクチャに応じて、冗長ソリューションでデータベースの破損に対応できる必要があります。

12.1.1.3 ハードウェア・レベルの冗長性

ここでは、ハードウェアの冗長性に関する基本情報を示します。ハードウェアの冗長性を使用して高可用性を確保するための包括的な情報は、数多くの出版物に記載されています。特に、John Wiley & Sons, Inc.が発行している『Blueprints for High Availability』(http://www.amazon.com/exec/obidos/tg/detail/-/0471430269/qid=1105613280/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-6680176-0680863?v=glances=booksn=507846)を参照してください。

ハードウェアSPOFは、大きく次のように分類できます。

- ネットワークの障害

- Directory ServerやDirectory Proxy Serverが実行されている物理サーバーの障害

- ロード・バランサの障害

- ストレージ・サブシステムの障害

- 電源障害

ネットワーク・レベルの障害は、冗長なネットワーク・コンポーネントを配置することで軽減できます。デプロイメントを設計するときに、次の冗長コンポーネントの配置を検討してください。

- インターネット接続

- ネットワーク・インタフェース・カード

- ネットワーク配線

- ネットワーク・スイッチ

- ゲートウェイとルーター

アーキテクチャに冗長ロード・バランサを含めることによって、ロード・バランサがSPOFになる可能性を軽減できます。

データベースの破損が発生した場合は、可用性を確保するためのデータベース・フェイルオーバー方針が必要になります。冗長サーバー・コントローラを使用して、ストレージ・サブシステムのSPOFを軽減できます。コントローラとストレージ・サブシステム、冗長ストレージ・サブシステム・コントローラまたはRedundant Array of Independent Disks間で冗長配線を使用することもできます。

電源が1つのみの場合は、その電源が失われると、サービス全体が使用できなくなる可能性があります。この状況を回避するために、可能な場合はハードウェアに対する冗長電源を用意したり、電源を多様化することを検討してください。電源におけるSPOFを軽減する他の方法として、サージ保護装置、複数の電力会社およびローカル・バッテリ・バックアップの使用、ローカルでの発電などをあげることができます。

たとえば、特定の地理的領域での自然災害によって、データ・センター全体の障害が発生する可能性があります。この場合、適切に設計された、複数のデータ・センターのレプリケーション・トポロジにより、分散したディレクトリ・サービス全体が使用できなくなることを回避できます。詳細は、「高可用性のためのレプリケーションおよび冗長性の使用」を参照してください。

12.1.1.4 ソフトウェア・レベルの冗長性

Directory ServerまたはDirectory Proxy Serverの障害には、次のようなものがあります。

- 極端に長いレスポンス時間

- 書込みの過負荷

- 最大化されたファイル記述子

- 最大化されたファイル・システム

- 適切でないストレージ構成

- 過剰な索引

- 読取りの過負荷

- キャッシュの問題

- CPUの制約

- レプリケーションの問題

- 同時発生

- レプリケーション伝播の遅延

- レプリケーションのフロー

- レプリケーションの過負荷

- 大規模なワイルドカード検索

これらのSPOFは、Directory ServerおよびDirectory Proxy Serverの冗長インスタンスを配置することによって軽減できます。ソフトウェア・レベルの冗長性では、レプリケーションが使用されます。レプリケーションにより、冗長サーバーが同期された状態に保たれ、停止時間なしでリクエストを再ルーティングできることが確実になります。詳細は、「高可用性のためのレプリケーションおよび冗長性の使用」を参照してください。

12.2 高可用性のためのレプリケーションおよび冗長性の使用

レプリケーションを使用すると、単一のサーバーが失われたことでディレクトリ・サービスが使用できなくなることを回避できます。信頼性のあるレプリケーション・トポロジを適用することにより、サーバーで障害が発生しても、複数のデータ・センターにわたるクライアントで、最新のデータを確実に使用できます。少なくとも、ローカル・ディレクトリ・ツリーを1つ以上のバックアップ・サーバーにレプリケートする必要があります。データの信頼性を最大化するには、物理的な場所ごとに3回レプリケートする必要があると考えるディレクトリ・アーキテクトもいます。フォルト・トレランスのためにレプリケーションをどの程度使用するかを決定するときは、ディレクトリで使用されるハードウェアとネットワークの品質を考慮します。信頼性の低いハードウェアに対しては、より多くのバックアップ・サーバーが必要になります。

レプリケーションを定期的なデータ・バックアップ・ポリシーのかわりに使用しないでください。ディレクトリ・データのバックアップの詳細は、「バックアップおよびリストア・ポリシーの設計」および『Oracle Directory Server Enterprise Edition管理者ガイド』の第8章「Directory Serverのバックアップおよびリストア」を参照してください。

LDAPクライアント・アプリケーションは、通常、1つのLDAPサーバーのみを検索するように構成します。異なるDNSホスト名に配置されたLDAPサーバーをローテーションするように、カスタム・クライアント・アプリケーションを作成できます。それ以外の場合、LDAPクライアント・アプリケーションは1つのDNSホスト名でのみDirectory Serverを検索するように構成できます。Directory Proxy Server、DNSラウンド・ロビンまたはネットワーク・ソートを使用して、バックアップDirectory Serverへのフェイルオーバーを提供できます。DNSラウンド・ロビンまたはネットワーク・ソートの設定および使用の詳細は、DNSのドキュメントを参照してください。このコンテキストでDirectory Proxy Serverを使用する方法の詳細は、「冗長ソリューションの一部としてのDirectory Proxy Serverの使用」を参照してください。

ディレクトリのデータを読み取る機能を維持するには、適切なロード・バランシング方針を適用する必要があります。読取り負荷を複数のレプリカに分散するために、ソフトウェアとハードウェアの両方のロード・バランシング・ソリューションが存在します。これらの各ソリューションでは、各レプリカの状態を確認したり、そのローカル・バランシング・トポロジへの参加を管理することもできます。ソリューションは、完全性と正確さに関して異なることがあります。

地理的に離れたサイトへの書込みフェイルオーバーを維持するために、WAN上で複数のデータ・センター・レプリケーションを使用できます。このためには、データ・センターごとに少なくとも2つのマスター・サーバーを設定し、サーバーをWAN上で完全にメッシュ化するように構成します。この方針により、トポロジ内のいずれかのマスターで障害が発生した場合に、サービスの損害が回避されます。書込み可能サーバーが使用できなくなった場合は、書込み操作を代替サーバーにルーティングする必要があります。Directory Proxy Serverなど、様々な方法を使用して書込み操作を再ルーティングできます。

次の各項では、高可用性を確保するためにレプリケーションおよび冗長性を使用する方法について説明します。

- 冗長レプリケーション承諾の使用

- レプリカの昇格と降格

- 冗長ソリューションの一部としてのDirectory Proxy Serverの使用

- 高可用性のためのアプリケーション分離の使用

- 高可用性のために冗長性を使用するサンプル・トポロジ

12.2.1 冗長レプリケーション承諾の使用

冗長レプリケーション承諾を使用すると、障害の発生時に迅速なリカバリが可能になります。レプリケーション承諾を有効および無効にできることは、元のレプリケーション・トポロジで障害が発生した場合にのみ使用されるレプリケーション承諾を設定できることを意味します。この操作は手動ですが、この方針を使用すると、必要に応じてレプリケーション承諾の設定を待機するよりも大幅に時間を短縮できます。冗長レプリケーション承諾の使用方法の説明は、「高可用性のために冗長性を使用するサンプル・トポロジ」を参照してください。

12.2.2 レプリカの昇格と降格

レプリカの昇格または降格により、レプリケーション・トポロジにおけるレプリカのロールが変化します。専用コンシューマとハブが含まれた非常に大規模なトポロジでは、高可用性の方針の一部として、レプリカのオンラインでの昇格および降格を含めることができます。たとえば、追加のロード・バランシングおよびフェイルオーバー用に2つのハブが構成されたマルチマスター・レプリケーション・シナリオを考えます。1つのマスターがオフラインになった場合は、最適な読取り/書込みの可用性を維持するために、いずれかのハブをマスターに昇格できます。マスター・レプリカがオンラインに戻ったときは、単にハブ・レプリカに降格することで、元のトポロジに戻ります。

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格と降格に関する説明を参照してください。

12.2.3 冗長ソリューションの一部としてのDirectory Proxy Serverの使用

Directory Proxy Serverは、高可用性ディレクトリ・デプロイメントをサポートするように設計されています。このプロキシは、自動ロード・バランシングおよび一連のレプリケートされたDirectory Server間の自動フェイルオーバーや自動フェイルバックを提供します。トポロジ内の1つ以上のDirectory Serverが使用できなくなると、負荷は残りのサーバーに均等に再分散されます。

Directory Proxy ServerはアクティブにDirectory Serverを監視して、サーバーがまだオンラインであることを確認します。プロキシは、実行された各操作のステータスも調べます。すべてのサーバーでスループットとパフォーマンスが同じであるとはかぎりません。プライマリ・サーバーが使用できなくなった場合、セカンダリ・サーバーに一時的にリダイレクトされたトラフィックは、プライマリ・サーバーが使用できるようになると、すぐにプライマリ・サーバーに戻されます。

データを分散する場合は、複数の切断されたレプリケーション・トポロジを管理する必要がありますが、これにより、管理が複雑になります。さらに、Directory Proxy Serverでは、ユーザー認可の管理をプロキシ認可制御に大きく依存しています。分散に関与する各Directory Serverに特定の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシ・アクセス制御権限を付与する必要があります。

12.2.4 高可用性のためのアプリケーション分離の使用

Directory Proxy Serverを使用して、レプリケートされたディレクトリ・サービスを問題のあるクライアント・アプリケーションが原因の障害から保護することもできます。可用性を改善するには、一連の制限されたマスターまたはレプリカを各アプリケーションに割り当てます。

問題のあるアプリケーションが特定のアクションを実行したときに、サーバーがシャットダウンされるとします。アプリケーションが連続する各レプリカにフェイルオーバーすると、あるアプリケーションに関する1つの問題が原因で、レプリケートされたトポロジ全体の障害が発生する可能性があります。このようなシナリオを回避するには、各アプリケーションのフェイルオーバーとロード・バランシングをかぎられた数のレプリカに制限できます。これにより、潜在的な障害はこの一連のレプリカに制限され、他のアプリケーションに対する障害の影響が減少します。

12.2.5 高可用性のために冗長性を使用するサンプル・トポロジ

次のサンプル・トポロジでは、冗長性を使用して障害が発生しても継続的なサービスを提供する方法を示します。

12.2.5.1 単一のデータ・センターにおける可用性を確保するためのレプリケーションの使用

次の図に示すデータ・センターには、3つのマスターを使用する、マルチマスター・トポロジがあります。このシナリオでは、3つ目のマスターは障害発生時の可用性を確保するためにのみ使用されます。問題が発生しない場合、読取り操作と書込み操作はDirectory Proxy Serverによってマスター1とマスター2にルーティングされます。リカバリを高速化し、レプリケーション承諾の数を最小限に抑えるために、リカバリ・レプリケーション承諾が作成されます。これらの承諾は、デフォルトでは無効ですが、障害の発生時に迅速に有効にできます。

図12-1 単一のデータ・センターにおけるマルチマスター・レプリケーション

「図12-1 単一のデータ・センターにおけるマルチマスター・レプリケーション」の説明

12.2.5.1.1 単一のデータ・センターの障害マトリックス

図12-1に示すシナリオでは、様々なコンポーネントが使用できなくなる可能性があります。これらの潜在的な障害ポイントおよび関連するリカバリ・アクションを次の表に示します。

表12-1 単一のデータ・センターの障害マトリックス

障害が発生したコンポーネント

アクション

マスター1

マスター1の修復中、読取り操作と書込み操作は、Directory Proxy Serverによってマスター2とマスター3に再ルーティングされます。マスター2とマスター3の間のリカバリ・レプリケーション承諾が有効になっているため、マスター3に対する更新はマスター2にレプリケートされます。

マスター2

マスター2の修復中、読取り操作と書込み操作は、マスター1とマスター3に再ルーティングされます。マスター1とマスター3の間のリカバリ・レプリケーション承諾が有効になっているため、マスター3に対する更新はマスター1にレプリケートされます。

マスター3

マスター3はバックアップ・サーバー専用であるため、このマスターで障害が発生しても、ディレクトリ・サービスは影響を受けません。マスター3は、サービスを中断することなくオフラインにして修復できます。

Directory Proxy Server

Directory Proxy Serverで障害が発生すると、サービスは中断されます。このトポロジでは、Directory Proxy Serverの冗長インスタンスを使用することをお薦めします、このようなトポロジの例は、「複数のDirectory Proxy Serverの使用」を参照してください。

12.2.5.1.2 単一のデータ・センターのリカバリ手順

3つのマスターのある単一のデータ・センターでは、1つのマスターで障害が発生しても、読取りおよび書込み機能は維持されます。この項では、障害が発生したコンポーネントを回復するために適用できるサンプル・リカバリ計画について説明します。

次のフローチャートおよび手順では、1つのコンポーネント、マスター1で障害が発生したとします。2つのマスターで同時に障害が発生した場合は、問題の修復中に読取りおよび書込み操作を残りのマスターにルーティングする必要があります。

図12-2 単一のデータ・センターのサンプル・リカバリ手順

「図12-2 単一のデータ・センターのサンプル・リカバリ手順」の説明

12.2.5.1.3 1つのコンポーネントで障害が発生した場合のリカバリ

1. マスター1がまだ停止されていない場合は停止します。

2. 障害の原因を特定します。

- ネットワーク・ケーブルの交換などによって障害を簡単に修復できる場合は、修復して手順2に進みます。

- 問題が深刻な場合は、障害の修復に時間がかかることがあります。手順3に進みます。

3. 深刻な障害のトラブルシューティングを行うには、次の手順に従います。

1. マスター1にアクセスするアプリケーションがマスター2またはマスター3を指すようにDirectory Proxy Serverによってリダイレクトされることを確認します。

2. 最新のバックアップを使用できるかどうかを確認します。
最新のバックアップを使用できる場合は、マスター1をバックアップから再初期化し、手順3に進みます。

最新のバックアップを使用できない場合は、次のいずれかを実行します。

マスター1を再起動し、マスター2またはマスター3からマスター1への全体的な初期化を実行します。

この手順の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの初期化に関する説明を参照してください。

全体的な初期化の実行時間が長すぎる場合は、マスター2またはマスター3からオンライン・エクスポートを実行し、マスター1にインポートします。

4. マスター1が起動していない場合は、起動します。

5. マスター1が読取り専用モードの場合は、読取り/書込みモードに設定します。

6. レプリケーションが正しく機能していることを確認します。
DSCCのdsccmon view-suffixesまたはinsyncコマンドを使用してレプリケーションを確認できます。

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリケーション・ステータスの取得に関する説明、dsccmonおよびinsyncを参照してください。

12.2.5.2 2つのデータ・センターにわたる可用性のためのレプリケーションの使用

一般的に、2つのデータ・センターのあるデプロイメントでは、単一のデータ・センターについて説明したものと同じリカバリ計画を適用できます。1つ以上のマスターが使用できなくなると、Directory Proxy Serverによって、ローカルの読取りおよび書込みが残りのマスターに自動的に再ルーティングされます。

前に説明した単一のデータ・センター・シナリオと同様に、リカバリ・レプリケーション承諾を有効にすることができます。これらの承諾により、両方のデータ・センターでは、障害が発生しても、引き続き、レプリケートされた更新を確実に受け取ることができます。このリカバリ計画を図12-3に示します。

リカバリ・レプリケーション承諾を使用するかわりに、すべてのマスターが変更を他のすべてのマスターにレプリケートする完全にメッシュ化されたトポロジを使用することもできます。レプリケーション承諾が少ないほど管理が容易になる可能性がありますが、完全にメッシュ化されたトポロジを使用しない技術的な理由は存在しません。

このシナリオにおける唯一のSPOFは、各データ・センターのDirectory Proxy Serverです。図12-4に示すように、冗長なDirectory Proxy Serverをデプロイすることで、この問題を解決できます。

図12-3 2つのデータ・センターにおけるリカバリ・レプリケーション承諾

「図12-3 2つのデータ・センターにおけるリカバリ・レプリケーション承諾」の説明

リカバリ計画は、障害が発生するコンポーネントの組合せに依存します。ただし、複数の障害に対処するための基本的な計画を適用した後、他のコンポーネントで障害が発生した場合にその計画を適用できます。

図12-3に示すサンプル・トポロジでは、ニューヨークのデータ・センターのマスター1とマスター3で障害が発生したと想定しています。

このシナリオでは、Directory Proxy Serverによって、ニューヨークのデータ・センターの読取りと書込みがマスター2とマスター4に自動的に再ルーティングされます。これにより、ニューヨークのサイトで、ローカルの読取りおよび書込み機能が確実に維持されます。

12.2.5.3 複数のDirectory Proxy Serverの使用

次の図に示すデプロイメントには、内部LDAPサービスへの外部アクセスを拒否するエンタープライズ・ファイアウォールがあります。内部で開始されたクライアントのLDAPリクエストは、ネットワーク・ロード・バランサによってDirectory Proxy Serverに送信され、IPレベルの高可用性が確保されます。Directory Proxy Serverを実行しているホストを除き、Directory Serverへの直接アクセスは防止されます。プロキシがSPOFになることを防止するために、2つのDirectory Proxy Serverがデプロイされています。

完全にメッシュ化されたマルチマスター・トポロジを適用すると、他のマスターで障害が発生しても、確実に、いつでもすべてのマスターを使用できます。わかりやすくするために、この図には、一部のレプリケーション承諾のみ示されています。

図12-4 内部の高可用性構成

「図12-4 内部の高可用性構成」の説明

12.2.5.4 アプリケーション分離の使用

次の図に示すシナリオでは、アプリケーション1のバグによってDirectory Serverで障害が発生します。プロキシ構成により、アプリケーション1からのLDAPリクエストは、確実にマスター1とマスター3に送信されます。バグが発生すると、マスター1とマスター3で障害が発生します。ただし、アプリケーション2、3および4はまだ動作中のDirectory Serverにアクセスできるため、無効になりません。

図12-5 スケーラビリティを持つデプロイメントにおけるアプリケーション分離の使用

「図12-5 スケーラビリティを持つデプロイメントにおけるアプリケーション分離の使用」の説明

第IV部

高度なデプロイメント

ここでは、特殊なデプロイメントについて説明します。次の章で構成されます。

- 第13章「SolarisでのLDAPベースのネーミングの使用」では、LDAPベースのネーミングについて説明します。

- 第14章「仮想ディレクトリのデプロイ」では、Directory Proxy Serverの仮想化機能について説明します。

- 第15章「同期データを含むデプロイメントの設計」では、Identity Synchronization for Windowsを使用するデプロイメントについて説明します。

13 SolarisでのLDAPベースのネーミングの使用

この章では、Solarisオペレーティング・システム(Solaris OS)に用意されているLDAPネーミング・サービスの概要を示します。Solaris OSでサポートされているネーミング・サービスの詳細は、『システム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP編)』の第I部「ネーミングとディレクトリサービスについて」を参照してください。

この章の内容は、次のとおりです。

- LDAPベースのネーミング・サービスを使用する理由

- NISからLDAPへの移行

- NIS+からLDAPへの移行

13.1 LDAPベースのネーミング・サービスを使用する理由

ネーミング・サービスは中央の場所に情報を格納するため、ユーザー、マシンおよびアプリケーションはネットワーク上で通信できます。この情報には、マシン(ホスト)の名前とアドレス、ユーザー名、パスワード、アクセス権限、グループ・メンバーシップ、プリンタなどが含まれます。中央のネーミング・サービスがない場合は、各マシンでこの情報の独自のコピーを保持する必要があります。ネーミング・サービス情報は、ファイル、マップまたはデータベース表に格納できます。すべてのデータを集中管理すると、管理がより容易になります。

Solaris OSでは、次のネーミング・サービスがサポートされています。

- DNS (ドメイン・ネーム・システム)

- /etcファイル(元のUNIXネーミング・システム)

- NIS (ネットワーク情報サービス)

- NIS (ネットワーク情報サービス・プラス)

- LDAP (Lightweight Directory Access Protocol)

ただし、オラクル社では、LDAPベースのネーミング・サービスに移行する方針です。

LDAPネーミング・サービスには、他のネーミング・サービスと比べて次の利点があります。

- アプリケーション固有のデータベースを置き換えることによって情報を統合できるため、管理対象の異なるデータベースの数が少なくなります。

- データを異なるネーミング・サービスで共有できます。

- データの中央リポジトリが提供されます。

- マスター・サーバーとレプリカ間でのデータ同期の頻度を上げることができます。

- 複数のプラットフォームおよびベンダーと互換性があります。

LDAPネーミング・サービスには、他の制限があります。

- Solaris 8よりも前のクライアントはサポートされません。

- LDAPネーミング・サービスの設定および管理は複雑であるため、より慎重に計画する必要があります。

- NISクライアントおよびネイティブLDAPクライアントは、同じクライアント・マシンに共存できません。

Solaris OSでは、LDAPネーミングとOracle Directory Serverおよび他のLDAPディレクトリ・サーバーの組合せがサポートされています。Oracle Directory Serverを使用することをお薦めしますが、必須ではありません。

13.2 NISからLDAPへの移行

NISからLDAPへの移行は、データ移行とクライアント移行の2つの手順で構成されています。Solaris OSは、両方の手順を実行するNISからLDAPへの移行サービス(N2Lサービス)を提供します。

N2Lサービスによって、NISマスター・サーバー上の既存のNISデーモンが、NISからLDAPへの移行デーモンに置き換えられます。また、NISからLDAPへのマッピング・ファイルも、N2Lサービスによってそのサーバー上に作成されます。マッピング・ファイルでは、NISマップ・エントリとLDAPの対応するディレクトリ情報ツリー(DIT)エントリ間のマッピングが指定されています。この移行を通過したNISマスター・サーバーは、N2Lサーバーと呼ばれます。

NISスレーブ・サーバーは、通常どおり動作を続けます。スレーブ・サーバーは、N2Lサーバーが通常のNISマスターである場合と同様、N2Lサーバーからデータを定期的に更新します。inityp2lスクリプトは、これらの構成ファイルの初期設定に役立ちます。N2Lサーバーが設定されると、構成ファイルを直接編集してN2Lを保守できるようになります。

N2Lサービスでは、次の操作がサポートされています。

- LDAP DITへのNISマップのインポート

- NISの速度および拡張性によるDIT情報へのクライアント・アクセス

NISからLDAPに移行する方法の詳細は、システム管理ガイド: ネーミングおよびディレクトリ・サービス(DNS、NISおよびLDAP)の第15章「NISからLDAPへの移行(概要/タスク)」を参照してください。

13.3 NIS+からLDAPへの移行

NIS+データとLDAPの同期を維持できますが、以前は、このような同期には外部エージェントが必要でした。ただし、現在はNIS+デーモンにより、LDAPサーバーをNIS+データのデータ・リポジトリとして使用できるようになりました。この機能を使用すると、NIS+およびLDAPクライアントで同じネーミング・サービス情報を共有できます。したがって、メイン・ネーミング・サービスとしてNIS+を使用する状態から、同じロールでLDAPを使用する状態への移行が容易になりました。

14 仮想ディレクトリのデプロイ

仮想ディレクトリはDirectory Proxy Serverの拡張機能であり、複数のデータ・リポジトリから、リアルタイムに情報を集約します。この章では、Directory Server Enterprise Editionデプロイメントで仮想ディレクトリを使用する方法について説明します。

仮想ディレクトリのアーキテクチャの概念は、Oracle Directory Server Enterprise Editionリファレンスの第18章「Directory Proxy Serverの仮想化」に記載されています。仮想ディレクトリの設定手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第22章「Directory Proxy Serverの仮想化」に記載されています。

この章の内容は、次のとおりです。

- 仮想ディレクトリを使用するタイミング

- 一般的な仮想ディレクトリ・シナリオ

14.1 仮想ディレクトリを使用するタイミング

ディレクトリ・サービスに次のいずれかの要件がある場合は、仮想ディレクトリ機能をデプロイできます。

- 複数のデータ・リポジトリ上のエントリの集約ビューがクライアント・アプリケーションで必要です。
たとえば、同じユーザーが含まれ、データが異なるいくつかのディレクトリ・サーバーがあるとします。仮想ディレクトリを使用して、あるユーザーのすべてのディレクトリにわたるエントリに対する、単一のビューを作成できます。仮想ディレクトリを使用すると、個々のディレクトリをシングル・ポイントから管理することもできます。

サポートされているデータ・リポジトリのタイプには、LDAPディレクトリ、MySQLなどのJava Database Connectivity (JDBC)に準拠したソースおよびLDIFフラット・ファイルがあります。

- ユーザー資格証明およびアプリケーション固有データにそれぞれ異なるデータ・ソースが必要です。
たとえば、アプリケーションには、コーポレート・ディレクトリに格納する必要がない固有データが存在する場合があります。仮想ディレクトリを使用すると、そのようなデータを分離し、アプリケーションの1つのソースとして見えるようにすることができます。これにより、アプリケーションでデータ・インフラストラクチャの詳細を把握する必要がなくなるため、アプリケーション開発とデータ管理が簡略化されます。さらに、バックエンド・データ・ソースへの変更をアプリケーションから抽象化できます。

- 企業が別の企業を買収したか、別の企業と合併しました。
仮想ディレクトリを使用すると、2つの企業ディレクトリをマージして、1つのディレクトリとして見えるようにすることができます。たとえば、dc=example,dc=comおよびdc=acquisition,dc=comという2つのディレクトリを考えます。クライアント・アプリケーションで両方のディレクトリがdc=example,dc=comとして見えるようにする必要があります。

- クライアント・アプリケーションでデータベース表をDIT階層の形式で表示する必要があります。

- 複数のデータ・リポジトリに対する読取り操作および書込み操作が必要です。

- 属性名が異なる複数のフィールド結合基準が必要です。

- 複数のLDAPやJDBCバックエンドからの、ディレクトリやデータベースをまたぐ複数値属性のサポートが、クライアント・アプリケーションで必要です。

- 属性名の変更、DNの書換えおよびDN構文属性の属性値の書換えが必要です。

- 複数のクライアント・アプリケーションで単一データ・リポジトリの異なるビューが必要です。

14.2 一般的な仮想ディレクトリ・シナリオ

この項では、仮想ディレクトリで特定のビジネス要件に対応する方法を示す単純なシナリオについて説明します。複雑なサンプル・シナリオおよび仮想ディレクトリ構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサンプル仮想構成に関する説明を参照してください。

14.2.1 異なるデータ・ソースのユーザー・アイデンティティの結合

Example.comストアでは、ユーザー・データを格納するために3つの異なるデータ・リポジトリが使用されています。Example.comのDirectory Serverにユーザー・データの大部分が格納されています。ユーザー電子メール・アドレスはActive Directoryに格納され、HRデータはMySQLデータベースに格納されます。

Example.comには、すべてのユーザー・データの完全なビューを必要とするいくつかのクライアント・アプリケーションがあります。次の図は、仮想ディレクトリによって、ユーザーのアイデンティティの完全なビューがクライアント・アプリケーションにどのように提供されるかを示しています。

図14-1 複数リポジトリからの集約データの仮想ビュー

「図14-1 複数リポジトリからの集約データの仮想ビュー」の説明

15 同期データを含むデプロイメントの設計

Identity Synchronization for Windowsは、Directory Server Enterprise Editionのコンポーネントであり、パスワードなどのユーザー・アカウント情報をDirectory ServerとWindowsの間で同期します。Windows Active DirectoryとWindows NTの両方がサポートされます。Identity Synchronization for Windowsは、どのような規模の企業においても、スケーラブルでセキュリティ機能が豊富なパスワード同期ソリューションの構築に役立ちます。

Identity Synchronization for Windowsの詳細は、http://download.oracle.com/docs/cd/E20295_01/index.htmを参照してください。デプロイメントでIdentity Synchronization for Windowsを使用する場合は、この章で説明する問題に対処する必要があります。

15.1 Identity Synchronization for Windowsデプロイメントの考慮事項

- パスワードの同期方向。パスワードをDirectory ServerからActive Directoryに、または両方の方向に同期する場合は、Windows 2000に高度暗号化パックをインストールします。このインストールにより、Active Directory over LDAPでパスワードを設定するときに必要な128ビットSSLが有効になります。

- 新しいユーザーの作成の同期。Identity Synchronization for Windowsで新しいユーザーの作成を同期しない場合は、idsync resyncコマンドを定期的に実行して、新しく作成したユーザー間のリンクを確立する必要があります。新しく作成されたユーザーの変更は、idsync resyncの実行によってユーザーが明示的にリンクされるまで同期されません。

- 移入サイズ。Identity Synchronization for Windowsでは、同期できるユーザーの数に上限は設定されていませんが、ユーザーの総数はデプロイメントに影響します。主な影響は、同期の開始前に実行する必要があるidsync resyncコマンドに対するものです。100,000を超えるユーザーを同期する場合は、idsync resyncコマンドをバッチで実行します。このバッチ・モードにより、最適なパフォーマンスが確保され、Sun Message Queueの負荷が制限されます。

- パフォーマンス要件。Identity Synchronization for Windowsのパフォーマンスは、ユーザーの総数よりも同期率によって制限されます。この要件の唯一の例外は、idsync resyncコマンドを実行する場合です。

- 予想される最大の変更率。同じシステムで実行されているコアおよび2つのコネクタを持つIdentity Synchronization for Windowsデプロイメントでは、1秒当たり10回の同期という変更率を容易に持続できます。必要な同期率がこの値を超える場合は、Identity Synchronization for Windowsを複数のマシンに分散することでパフォーマンスを向上できます。たとえば、コネクタをIdentity Synchronization for Windowsコアとは異なるマシンにインストールできます。

- 同期するWindowsドメインの数。複数のWindowsドメインを同期する場合は、activedirectorydomainname属性またはUSER_NT_DOMAIN_NAME属性をDirectory Server属性に同期する必要があります。この同期は、同期ユーザー・リスト定義間のあいまいさを解決するために必要です。

- デプロイメントにおけるDirectory Serverマスター、ハブおよび読取り専用レプリカの数。複数のDirectory Serverを含むデプロイメントでは、Identity Synchronization for Windows Directory Serverプラグインを各マスター、各ハブおよび各読取り専用レプリカで有効にする必要があります。Identity Synchronization for Windowsを構成するときに、1つのDirectory Serverマスターを優先マスターとして指定します。Directory Serverコネクタは、マスターの実行中に優先マスターで変更を検出し、適用します。このサーバーが停止すると、コネクタは必要に応じて2番目のマスターで変更を適用します。優先マスターでは、Retro Changelogプラグインを有効にする必要があります。このマスターは、Identity Synchronization for Windowsコアと同じLAN上に存在している必要があります。

- セキュリティ。Directory ServerまたはActive DirectoryコネクタがSSLを介してDirectory ServerまたはActive Directoryに接続する場合は、これらのサーバーでSSLを有効にする必要があります。信頼できる証明書のみを受け入れるようにコネクタが構成されている場合は、追加の構成手順が必要になります。これらの手順では、適切な認証局証明書をコネクタの証明書データベースにインポートします。Directory ServerプラグインとActive Directoryの間でSSLが必要な場合は、Directory ServerでSSLを有効にする必要があります。さらに、Active Directory SSL証明書に署名するために使用される認証局証明書をDirectory Serverの証明書データベースにインポートする必要があります。

Identity Synchronization for Windowsを組み込むデプロイメント・シナリオの詳細は、Identity Synchronization for Windowsのデプロイメント・プランニング・ガイドを参照してください。

索引

C  D  I  J  L  M  S

C

中央ログ・ディレクトリ, はじめに

証明書データベース

デフォルト・パス, はじめに

D

デフォルトの場所, はじめに

I

install-path, はじめに

instance-path, はじめに

isw- hostnameディレクトリ, はじめに

J

Java Naming and Directory Interface, はじめに

L

ローカル・ログ・ディレクトリ, はじめに

M

Message Queue, はじめに

S

serverrootディレクトリ, はじめに

SLAMD分散負荷生成エンジン, はじめに

Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved.