ここでは、構築モジュールソリューションを配備するためのガイドラインを説明します。
構築モジュールの構築方法によってはパフォーマンスに影響します。
構築モジュールを適切に配備するためには、次に示す推奨事項を考慮してください。
1 台のマシンに 1 つの構築モジュールを配備します。
複数のマシンを使用する場合、または Portal Server マシンが多数のインスタンスを稼働させている場合は、高速ネットワークインターコネクトを使用します。
8 個を超える CPU が搭載されているサーバーでは、2 個または 4 個の CPU からなるプロセッサセットまたはドメインを作成します。たとえば、Portal Server の 2 つのインスタンスを 8 個の CPU が搭載されたサーバーにインストールする場合は、4 個の CPU からなる 2 つのプロセッサセットを作成します。
構築モジュールを配備するための Directory Server の要件を確認します。Directory Server の配備の特定の情報は、『Directory Server 配備計画ガイド』を参照してください。
Portal Server の配備を計画する際には、次に示す Directory Server のガイドラインを考慮してください。
Directory Server コンシューマレプリカプロセッサセットに必要な CPU の量は、構築モジュールに含まれる Portal Server インスタンスの数、またパフォーマンスおよび容量の考慮事項によって決定されます。
可能であれば、1 つの Directory Server インスタンスを1 つの構築モジュール内の Portal Server インスタンス専用にします。
ディレクトリデータベースインデックス全体とメモリー内のキャッシュをマップして、ディスクの遅延に関する問題を防止します。
複数の構築モジュールを配備するときは、Directory Server サプライヤに対するプ ロファイルの更新とレプリケーションのオーバーヘッドによる障害を回避するためにマルチマスター構成を使用します。
構築モジュールのスケーラビリティーは、プロファイルの更新によって生じる LDAP の書き込みの数と LDAP データベースの最大サイズによります。
/tmp ディレクトリに _db ファイルがある場合に LDAP サーバーがクラッシュすると、サーバーが再起動するときにこのファイルは失われます。これはパフォーマンスを向上させますが、可用性にも影響します。
特定のサイトの分析結果が、LDAP の書き込み操作が実際に制約となっていることを示す場合は、この問題の解決策として、受信要求をポータルの適切なインスタンスに転送するディレクトリの特定の分岐とその前にある層のみをレプリケートする構築モジュールを作成することができます。
検索エンジンを構築モジュールソリューションの一環として配備するときには、次の点を考慮してください。
各構築モジュールでは、1 つの Portal Server インスタンスだけの検索エンジンデータベースにリソース記述 (RD) が含まれているようにします。残りの Portal Server インスタンスの検索エンジンデータベースは、デフォルトの空の状態であるようにします。
ポータルの検索データベースに構築モジュールを使用するかどうかに影響する要素には、同時並行検索の数に加えて、Portal Server 配備の検索活動の程度、検索のヒットの範囲、すべてのユーザーの検索ヒットの平均数があります。たとえば、検索エンジンによるサーバーへの負荷は、大きなインデックスや高負荷のクエリーの場合はメモリーと CPU の両方をかなり使用することがあります。
検索機能を Portal Server とは別のマシンにインストールして、主なサーバーをポータルの活動専用にすることができます。そのようにする場合、検索プロバイダの searchURL プロパティーを使用して、検索機能がインストールされた 2 番目のマシンを指すようにします。検索インスタンスは、通常のポータルインスタンスです。ポータルインスタンスをインストールするのと同様に検索インスタンスをインストールしますが、検索インスタンスは検索機能のみに使用します。