WebSphere Portal 7

第 1 版

公開日: 2010 年 9 月

この資料について

IBM のアクセシビリティーに関するコミットメントに従い、この資料はアクセシビリティーに対応しています。

印刷

この資料を印刷する場合、最良の印刷出力を得るために、一部の装飾は除去されます。 以下に印刷についてのいくつかのヒントを示します。
  • この資料の長さは、ブラウザーで印刷可能な長さを超えている可能性があります。 Microsoft Internet Explorer では、大きなファイルを正しく印刷できることが実証されています。
  • この資料はボリュームの大きな資料です。 印刷プレビュー機能を利用して、印刷されるページの長さを確認してください。
  • 資料のセクションを強調表示して、その選択部分の内容だけを印刷することもできます。

オフラインでの作業

ブラウザーからこの資料のローカル・コピーを保存することができます。 メニューおよびオプションはブラウザーごとに異なります。 資料をローカルに保存する方法について詳しくは、ブラウザーのヘルプを参照してください。

フィードバックを送る

この資料のフィードバックをお送りになりたい場合は、 「フィードバックを送る」をご覧ください。

製品の概要

IBM® WebSphere® Portal は、ミドルウェア・アプリケーション (ポートレットと呼ばれます)、マッシュアップ、およびセキュアな business-to-business (B2B)、business-to-consumer (B2C)、および business-to-employee (B2E) ポータルの作成および管理のための開発ツールで構成されています。 Web ポータルを使用することにより、パートナー、従業員、および顧客は、ユーザー・エクスペリエンスを選択できます。 つまり、役割、コンテキスト、アクション、ロケーション、設定、およびチーム・コラボレーションの要件に基づいて、アプリケーションをパーソナライズできます。 IBM WebSphere Portal ソフトウェアでは、複合アプリケーション、つまりビジネス・マッシュアップ・フレームワークと、柔軟な SOA ベースのソリューションを構築するために必要な拡張ツールが提供されます。さらに、あらゆる規模の組織の必要に応える無類のスケーラビリティーも備えています。

WebSphere Portal のサーバー・オファリングには、パーソナライゼーションおよび生産性の機能が、スケーラブルなポータル・フレームワークと共に用意されています。 IBM WebSphere Portal Server は、WebSphere Portal 製品ファミリーの基盤となるオファリングで、アプリケーションとコンテンツを役割ベースのアプリケーションに簡単に統合して、検索、パーソナライゼーション、およびセキュリティーの各機能を装備させる、エンタープライズ・ポータル機能を備えています。

Content Accelerator および Enable オファリングでは、 IBM Lotus Web Content Management、文書管理、エンタープライズ・サーチ、および拡張ワークフローといった各機能が追加されます。また、Extend オファリングには、ポータルの効果性を高めるための強力なコラボレーション機能が含まれています。これには、チーム・コラボレーション、電子フォーム、インスタント・メッセージング、および在席認識サービスが含まれます。 追加の IBM アクセラレーター・オファリングでは、WebSphere Portal ソフトウェアに簡単にスナップオンする追加のソリューションが提供されるため、評価時間を削減でき、お客様がコンテンツのデプロイ、ビジネス・プロセスの自動化、コラボレーションを行うときにかかるコストを削減できるようにします。

ポータルとは、Web ベースのリソースへのアクセスを 1 つの場所に集約することにより、ユーザーにこれらのリソースへの単一アクセス・ポイントを提供する Web サイトです。ユーザーは使用するそれぞれのポートレットではなく、ポータル自体にログインするだけで済みます。 また WebSphere Portal は、WAP 対応デバイス、i モード電話、スマートフォン、および各種 Web ブラウザーに Web コンテンツを配信することもできます。 さらに IBM Mobile Portal Accelerator のマルチ・チャネル・サーバーおよびモバイル・デバイス・リポジトリーを使用することにより、市場のニーズに対応すべく、7000 を超えるモバイル・デバイスにポータル・コンテンツを動的に拡張し、新しい更新やデバイスが追加されています。

アドミニストレーターは、企業、ユーザー、およびユーザー・グループのニーズに合わせて、WebSphere Portal をカスタマイズすることができます。 ポータルの「外観と雰囲気」を自分の組織の規格に合わせたり、 ビジネス・ルールやユーザー・プロファイルに従って、ユーザーやグループの ページ・コンテンツをカスタマイズすることができます。 ビジネス・パートナー、カスタマー、従業員などのユーザーは、 さらに、ポータルのビューを独自にカスタマイズすることができます。 ユーザーは、ポートレットをページに追加し、 それらを任意に配置し、ポートレットのカラー・スキームを制御することができます。ポートレットを一か所に集約し、ユーザーに自分のデスクトップをカスタマイズする機能を 提供することにより、WebSphere Portal はユーザーに対し、効率的で、高い満足度が得られる業務方法を提供しています。

ポートレットは、WebSphere Portal の中心部分です。 ポートレットは、ポータル・ページ上の定義領域として表示される、再使用可能な特殊な Java サーブレットとして、多くの異なるアプリケーション、サービス、および Web コンテンツへのアクセスを提供します。 WebSphere Portal には、シンジケート・コンテンツの表示、XML の変換、 検索エンジンおよび Web ページへのアクセスのためのポートレットなど、 多くの標準ポートレットが同梱されています。 Lotus Notes®IBM Lotus® Domino® and Extended Products、IBM Lotus Sametime®IBM Lotus Quickr、IBM Lotus Connections、Microsoft Exchange、インスタント・メッセージングにアクセスするためのポートレットも組み込まれています。第三者のポートレットもいくつかあります。 例えば、エンタープライズ・リソース・プランニング (Enterprise Resource Planning) (ERP) ポートレット、ダッシュボード (Dashboards) ポートレット、ビジネス・インテリジェンス (Business Intelligence) ポートレット、プロセス管理 (Process Management) ポートレット、カスタマー・リレーションシップ・マネージメント (Customer Relationship Management) (CRM) ポートレットなどです。さらに、WebSphere Portal には、 ポートレット開発者がカスタム・ポートレットの作成に使用できる API も同梱されています。

また WebSphere Portal には Lotus Mashup ランタイムが組み込まれるようになったので、ポータルの内部でウィジェットを実行でき、ポートレットとウィジェットの両方から成るマッシュアップを作成することもできます。ウィジェットは、JavaScript で作成された、高度な対話式ユーザー・インターフェース・コンポーネントです。 これらのウィジェットは一般に、有効範囲が非常に狭く、スクリプト・ベースの言語を使用して簡単に作成できます。 さらにウィジェットは、Java EE ベースのポータル・サーバーや PHP ベースのサーバーのようなさまざまなバックエンド・テクノロジー間のマッシュアップを作成するためのソリューションでもあります。

WebSphere プラットフォーム

WebSphere は IBM の統合ソフトウェア・プラットフォームです。 これには、24x7 の基幹業務用オンデマンド Web アプリケーションや、クロスプラットフォーム、クロス・プロダクトのソリューションを作成、実行、およびモニターするために必要なミドルウェア・インフラストラクチャー全体 (サーバー、サービス、ツールなど) が含まれます。 WebSphere は、信頼できる柔軟で堅固な統合ソフトウェアを提供しています。

WebSphere では、サービス指向アーキテクチャー (SOA) 環境用のソフトウェアが提供され、動的で相互接続されたビジネス・プロセスを使用できるようになり、すべてのビジネス・シチュエーションに対応する非常に効果的なアプリケーション・インフラストラクチャーが提供されます。

IBM WebSphere Application Server によって、サービス指向アーキテクチャー (SOA) アプリケーションおよびサービスを構築、再利用、実行、統合、および管理するためのパフォーマンス・ベースの革新的基盤が、非常に多くの開発者と IT アーキテクトに提供されます。これを活用することで、ビジネスにおける俊敏性が向上します。 ビジネス上不可欠で重要な企業規模のアプリケーションから、最小部門レベルのアプリケーションに至るまで、WebSphere Application Server は、最高レベルの信頼性、可用性、セキュリティー、およびスケーラビリティーを提供します。

新機能、主要コンポーネント、および各コンポーネントがソリューション全体に提供する機能についての追加情報は、このセクションのサブトピックを調べてください。

以下のトピックに、追加の概要情報があります。

新機能

IBM WebSphere Portal の新機能について説明します。

IBM WebSphere Portal の新機能および改良機能

WebSphere Portal には、仮想化、コンテンツのタグ付けおよびレーティングなどの新機能があり、さらにページ・ビルダーの機能拡張や、統一されたテーマ体系、保守容易性、マイグレーション、およびコンテンツ・マネジメントなどにおける機能拡張があります。

ConfigEngine

IBM サポートにより公開された問題報告の自動ログ収集を補助する、新しいタスクが追加されました。 これは、IBM 提供の ISA / ISA-lite サポート・ツールで使用できるログ収集に追加されたものです。 ConfigEngine タスクでログ収集を実行するために追加コードをインストールする必要はありません。

情報ポートレット

現在 2 つの情報ポートレットを使用できるようになりました。 これらのポートレットの機能は同じですが、元のポートレットは IBM API で作成され、新しいポートレットは JSR 286 API で作成されました。 新しいポートレットは、クライアントとサーバーの両サイドで表示できますが、元の情報ポートレットはサーバー・サイドでしか表示できません。

構成ウィザード

構成ウィザードが改良され、LDAP サーバーによる WebSphere Portal セキュリティーの構成が簡単になりました。 新しい構成ウィザード機能では、LDAP セキュリティー構成を正常に行うために答える必要のある各種質問に対し、LDAP サーバーの照会を試行することによって、より適切なデフォルトが提供されるようになりました。

構成ウィザードについてさらに調べる

ブログおよび Wiki

ページ・ビルダー・テーマで「コンテンツの追加」ウィジェットを使用して、ブログ、ブログ・ライブラリー、または Wiki をページに簡単に追加できるようになりました。 グローバリゼーション・サポートには、新しい IBM Lotus Web Content Management API を利用する、追加の拡張機能があります。

ブログおよび Wiki についてさらに調べる

エラー報告

ヒープ・メモリー使用に関係する同種の問題に対する WebSphere Portal の「First Failure Data Capture」特性を向上させるため、WebSphere Portal インストール済み環境のデフォルトでは、WebSphere Portal JVM での冗長なガーベッジ・コレクションがアクティブになります。 これは、WebSphere Application Server 内の WebSphere Portal JVM の JVM コマンド行引数に適切な設定を追加することによって行います。 これにより、基礎となる JVM で提供される、Java ヒープのガーベッジ・コレクション・アクティビティーに関する統計をログに記録するためのサポートがアクティブになります。

さらに、「ログ・ローリング」機能をサポートするプラットフォームでは、その機能がアクティブになり、ログにより使用される実際のディスク・スペース量を節約しながら、デバッグの際に必要な十分の量のガーベッジ・コレクション履歴を取り込む操作のバランスが取られます。 通常の冗長なガーベッジ・コレクションでは、ログが無制限に拡大する可能性があります。 ログ・ローリング機能を使用すれば、ログの生成は道理にかなった回数に制限され、生成される各ログに含まれるガーベッジ・コレクション・サイクル・レポートの数も制限されます。 WebSphere Portal でアクティブになるのは、基礎となる JVM コードで提供されるサポートであるため、このサポートの作動方法の詳細は、該当する Java 診断ガイドに記載されています。

この大量の割り振りロギングは、WebSphere Application Server 内のポータル・サーバー用に登録済みの JVM コマンド行パラメーターによりアクティブになり、WebSphere Application Server 構成内の該当するストリングを編集または削除することにより、調整または非アクティブにできます。 例えば、割り振りが「予定より大きいが 10 MB 未満」であると思われる場合、10 MB のしきい値を小さい値に引き下げることができます。

ロギングおよびトレースについてさらに調べる

Java 診断ガイドについてさらに調べる

メッセージ

メッセージ・カタログが更新されました。追加された新しいメッセージには、 ユーザーおよび IBM サポートの問題判別手順における助けとなるより詳しい説明と、提案されるユーザー処置が記載されます。 新しい項目に加えて、既存の共通エラー・メッセージが問題判別に役立つように改訂されました。

マイグレーション

マイグレーション・パスが改良され、WebSphere Portal バージョン 6.1 からのマイグレーションが、ソフトウェア・アップグレードにより近い形になりました。 WebSphere Portal バージョン 6.1 と 7.0 の間でのデータベース・スキーマの変更が、自動的に処理されます。 また、同じ場所でもデータベース・アップグレードを実行できます。

マイグレーションについてさらに調べる

複数のプロファイル

仮想化テクノロジーにより、ご使用のポータルをインストールおよび構成してから複数のプロファイルを作成し、それを使用してポータル・ファームまたはクラスター環境を作成することができます。 ポータル・ファームは、高度にスケーラブルで可用性の高いサーバー環境を構築して保守するための簡単な方法です。 これは、デプロイメント・マネージャーで保守されないという点で、クラスター環境と異なります。

クラスターのセットアップについてさらに調べる

ポータル・ファームのセットアップおよび保守についてさらに調べる

ページ・ビルダーおよび統一されたテーマ体系

ページ・ビルダー・テーマが現在のデフォルトのテーマです。 ページ・ビルダー・テーマは、ポートレットとウィジェットに加えて、サーバー・サイドとクライアント・サイド両方のページの集約をサポートする新しく統一された体系に進化しました。 テーマは、WebDAV ファイル・ストアに格納された静的 HTML ファイルを直接介して、編集と管理を完全に行えるようになりました。 スタイルがさらに最適化されました。線形グラデーション、立体の影付け、および角の丸めのために最新の CSS3 機能を活用することにより、パフォーマンスが向上し、カスタマイズが容易になりました。

既存のページ・ビルダー機能が改良されて、新しく機能強化されたクライアント・サイド集約体系をサポートするようになりました。 タブ・ナビゲーション・ウィジェットには、ドロップダウン・メニュー、インライン・ページ作成、およびドラッグ・アンド・ドロップによるページ再順序付けが装備され、 ブラウザーをフルページ最新表示しないでクライアント・サイドのページ切り替えをできるようになりました。 コンテンツ検索では、ページに追加するポートレットおよびウィジェットを検出します。 「スタイルの変更」および「レイアウトの変更」では、WebDAV により格納および構成される静的 CSS およびレイアウト・テンプレートをサポートします。

ページ・ビルダーについてさらに調べる

セキュリティー

偽名の使用 によりユーザー (サポート・スペシャリストなど) は、ユーザーのワークステーションにアクセスして新しいページ、ポートレットなどをテストし、ワークステーションで問題が発生したときにそれを調べることができます。 別のユーザーの偽名を使用する場合は、その前にまず偽名の使用の機能を使用可能にし、該当するユーザーに「ユーザーとして実行可能」の役割を割り当てる必要があります。

偽名の使用とその使用可能化の方法についてさらに調べる

タグ付けおよびレーティング

ユーザーはポータル・コンテンツへのタグ付けまたはレーティング、さらにタグとレーティングの表示を行えるようになりました。 これにより、ポータル・コンテンツ (ポータルにカスタム・コンテンツがある場合にはそれも含む) をより効率的に編成、分類、および検索することができます。 例えば、ユーザーはオンライン・ブック・ストアで本にタグ付けしたり、レーティングしたりすることができます。

ポータル・コンテンツのタグ付けおよびレーティングについてさらに調べる

ワークフロー管理システムとの統合

WebSphere Portal では、統一タスク・リストを使って、IBM WebSphere Process Server などのワークフロー管理システムとの単一の統合点を提供するようになりました。 統一タスク・リストは、視覚に訴える、高度に構成可能なユーザー・インターフェースの中に、複数のシステムからのタスクおよびアクティビティーを集約するポートレットです。 ポータル・ユーザーは、統一タスク・リストにアクセスして、ワークフローを進めるために完了できる保留タスクを表示および要求します。

統一タスク・リストは、WebSphere Portal Business Solutions Catalog から入手することができ、手を加えなくても WebSphere Process Server に統合できます。 しかし、統一タスク・リストはカスタマイズして、ユーザーのビジネス要件に適合させることができます。カスタマイズは、任意のワークフロー管理システムからタスクへのアクセス、検索、フォーマット設定を行う固有のタスク・プロバイダーまたはサービスを作成することによって行います。

統一されたタスク・リスト・ポートレットについてさらに調べる

仮想化

仮想化のテクノロジーを使用して、WebSphere Portal と共にインストールされて構成された同一のオペレーティング・システムを一括複製できます。 VMware は、WebSphere Portal のこのバージョンにおいて完全にサポートされています。

Linux での仮想化についてさらに調べる

Windows での仮想化についてさらに調べる

ドキュメンテーションの改善と変更

WebSphere Portal 7 では、お客様からのフィードバックに基づいて、ドキュメンテーションをさらに改善しました。 最も注目すべき変更点は、WebSphere Portal Family wiki でドキュメンテーションを発行するように移行していることです。

Wiki

Wiki が提供されたことで、インフォメーション・センターにもメリットがあります。 何か問題に気付いたり、改善の余地があると思ったりした場合、ユーザーはトピックにコメントを加えたり、それを編集したりできます。 以前は、フィードバック・フォームを IBM に送信することができました。 今まで多くのお客様が時間を取ってそれらのフォームを送信してくださり、優れたフィードバックをお寄せくださいました。 その結果として、ドキュメンテーションが更新され、改善されてきました。 新しい Wiki 配信形式では、そのようなフィードバックの効果が今までより早く他のお客様に提供されます。

どなたでも Wiki 上のドキュメンテーションをブラウズできます。 ただし、コンテンツの編集とコメント記入を行うには、Lotus developerWorks ID を使用して Wiki にログオンする必要があります。 既に Lotus developerWorks ID を持っているユーザーは、いつでもログオンしてコメントの追加または編集を行えます。 Lotus developerWorks ID を持っていないユーザーは、すぐに登録して始めることができます。

Lotus Registration

画面取りの中で、ドキュメンテーションを使用するときに知っておくべき機能が強調表示されています。

WebSphere Portal Family wiki ユーザー・インターフェースの画面取り。
画面取りの中で番号の付いた項目の説明については、表を参照してください。
表 1. 画面取りの凡例 - Wiki でドキュメンテーションを使用するときに、以下の主な機能を見逃さないでください。
番号 説明
1 パンくずは、現在の位置を見定めて、どの資料を読んでいるのかを素早く識別するのに役立ちます。
2 「拡張検索 (Advanced Search)」を選択すると、検索範囲を特定のカテゴリーに制限できる新しい画面が開きます。 例えば、検索範囲を IBM WebSphere Portal Express 7 ドキュメンテーションのトピックのみに制限することができます。 複数のカテゴリーでも単一のカテゴリーでも選択可能です。 拡張検索では、完全に一致する句の検出、タイトルのみの検索、単語単位のみでの検索、また検索におけるブール式の利用を行えます。 単一の用語または句を検索した後、選択条件やパラメーターを変更して、検索結果をさらに絞り込むことができます。
3 「ページ変換 (Translate page)」機能は、機械翻訳を使用して、すべてのコンテンツをその場で翻訳します。 多くの機械翻訳サーバーとは異なり、この機械翻訳サーバーはクラウド・ソーシングを使用します。 不正確、不自然、あるいは混乱させるような翻訳を見つけた場合、ユーザーがそれを訂正できます。 ユーザーが加えた修正は翻訳サーバーに追加され、次回そのコンテンツが翻訳されるときに使用されます。
4 IBM は引き続き、高い品質で翻訳されたコンテンツを提供します。 IBM 翻訳センターで翻訳されたドキュメンテーションにアクセスするには、ナビゲーションの「IBM 資料翻訳 (IBM Translated Documentation)」セクションを使用します。
5 これらのリンクを使用すると、参照中のトピックの元のバージョンを素早く表示できます。
6 ナビゲーションで強調表示された部分を見ると、現在のトピックが、コンテンツ内のその他のトピックに対してどのような相対位置にあるのかを知るのに役立ちます。

編成

WebSphere Portal 7 ドキュメンテーションのナビゲーションは、タスク指向に基づくもので、コンテンツをより迅速に検出するのに役立ちます。 この新しいナビゲーション・モデルは、他の IBM 製品とより一層調和しています。 ナビゲーション内の標準セクション (「インストール」、「開発」、「トラブルシューティング」など) に注目してください。 「セキュリティー」、「モニター (Monitoring)」、「ポータル・サイトのセットアップ (Setting up a portal site)」などの追加のナビゲーション・ヘッダーが追加されました。
  • 「セキュリティー」には、認証、SSL、LDAP 構成などについての情報が含まれています。
  • 「モニター (Monitoring)」には、ポータル・サイトの使用パターンについての理解を深めるのに役立つ情報が含まれています。
  • 「ポータル・サイトのセットアップ (Setting up a portal site)」には、サイトのセットアップを一層全体的に捉えられるようにコンテンツがまとめられています。 また、ページの作成、ポートレットのページへの追加、テーマとスキン、およびコンテンツのサイトへの追加に関する情報も含まれています。

WKPLC プロパティー

プロパティーの説明、例、およびデフォルト値が、ドキュメンテーションに復元されました。 プロパティー・ファイルのドキュメンテーションの検出

Lotus Web Content Management

Web Content Management への依存度が高いサイトをセットアップする場合には、IBM Lotus Web Content Management のドキュメンテーションを参照してください。 この新しいドキュメンテーション・セットは、サイトをセットアップするために WebSphere Portal および Lotus Web Content Management について知っておく必要のある事柄をまとめています。

資料リソース

情報の開始点は、製品資料です。 以前は、製品資料は、インフォメーション・センターのフレームワークを使用して配信されていましたが、WebSphere Portal 7.0 では、製品資料は WebSphere Portal Family wiki で配信されます。 WebSphere Portal の操作時に使用できるサイトやリソースが他にもありますが、情報の検索を容易にするためにこの統合が行われました。 また、コンテンツに改善を加え、資料に対してコミュニティー全体で編集およびコメント記入を行えるようにすることも意図しています。 情報の検索場所を知っていると、手間と費用を節約できます。 WebSphere Portal と Lotus Web Content Management の資料および補足コンテンツに関する 1 次リソースと 2 次リソースについて詳しく説明します。

コンテンツの 1 次ソースには、WebSphere Portal Family wiki および WebSphere Portal サポート・サイトの 2 つがあります。 優れた 2 次ソースとして developerWorks があります。ここには、例およびチュートリアル・ベースの記事があります。

コンテンツの 2 つの 1 次ソースである WebSphere Portal Family wiki およびサポート・ページを図示した概念的なグラフィック。さらにそれらに接続するハイパーリンク。
リソース間のナビゲートに役立つように、各コンテンツ・ソースは他のソースにリンクしています。 各コンテンツ・ソースには特定の目的があり、他のソースと併用することを意図しています。

Wiki で配信される製品資料 (「製品マニュアル (Product Documentation)」タブにある) は、予期される使用パターンに基づいて機能を活用できるように、IBM により開発されています。 ユーザーは製品を使用した経験を反映させることにより、コンテンツに貢献できます。 「ホーム」タブからアクセスする Wiki コンテンツは、IBM 内外のコミュニティーによって作成されます。 製品を使用した経験から得た、実際の使用パターンとユース・ケースに基づく知識を共有することを意図しています。 サポート・コンテンツは、IBM サポートによって、問題を避けたり診断したりするのに役立つように開発されており、可能な限り即応性があるよう意図されています。

WebSphere Portal Wiki

Wiki には、次の内容が含まれます。
  • 「製品マニュアル (Product Documentation)」タブには、次のものが含まれます。
    • 新しいフィーチャーのハイライト、製品フィーチャー、およびユーザー補助を含む製品の概説
    • デプロイメントの計画情報
    • 概念検証または開発サーバー用の単一サーバー、スタンドアロン実稼働、およびクラスター実稼働の各環境を対象にしたインストール指示
    • 通常 1 回、またはまれにしか指定されない、ポータル全体に影響する構成オプション
    • 毎日使用する管理タスク
    • 統合に関する指示
    • ポートレットや複合アプリケーションの開発に役立つ開発情報
    • トラブルシューティング情報と、ロギングおよびトレースの情報
    • 問題の診断やトラブルシューティングに役立つメッセージ
  • パフォーマンスおよびチューニング・ガイドなどの補足的な手引き
  • IBM Redbooks
  • ベスト・プラクティス
  • デプロイメント・シナリオ
  • タスク・ベースのデモンストレーションやビデオなどのマルチメディア・オファリング
  • 参照カード
Wiki に関して覚えておく必要があるキーポイントは以下のとおりです。
  • 以前はインフォメーション・センターで配信された情報は、現在 Wiki の「製品マニュアル (Product Documentation)」タブで配信されています。
  • コンテンツは体験主導型です。
  • ユーザーは記事を編集したり、コメントを追加したり、ユーザー独自の記事を作成したりできます。
  • IBM が Wiki をモニターします。
  • 新しい記事、コメント、および最新の編集に関して RSS フィードにサブスクライブできます。

WebSphere Portal Support ページ

Support ページには、次の内容が含まれます。
  • 製品か資料に伴う問題に対応して書き込まれた技術情報
  • フィックスの適用に関する指示を含む、フィックスパックのダウンロード
  • トラブルシューティング情報
  • 優先順位が高い問題に関するフラッシュ
Support ページに関して覚えておく必要があるキーポイントは以下のとおりです。
  • MyNotifications を使用して、更新や新規サポート・コンテンツにサブスクライブできます。
  • IBM Support Assistant などのツールをダウンロードできます。

多機能なフレームワーク

IBM WebSphere Portal により、ポータル・アプリケーション上で一貫したビューがユーザーに提供され、 ユーザーは、単一のコンテキストで提供される、特定のアプリケーションのセットを定義できるようになります。 要求を行うデバイスにより、そのデバイスの要件を満たすためのアプリケーション・セットの レンダリングは異なります。

デバイスから要求を受けるたびに、次の集約タスクを実行する必要があります。

  • ユーザー、デバイス、および選択言語に関する情報を収集する。
  • ユーザーにアクセス権があるアプリケーション・セットからアクティブなポートレットを選択する。
  • アクティブ・ポートレットの出力を一貫性があり使用可能な表示内容に集約する。

WebSphere Portal には、以下のフィーチャーを含む、カスタム・ナビゲーション・モデルを作成する機能も 用意されています。

  • 複数レベル・ナビゲーション
  • カスタマイズ済みテーマとスキン
  • カスタム・ナビゲーション - ナビゲーション・ツリーはポートレット自体によって提供される
  • ページ上でのポートレット (およびコンテンツ) のカスタム配置

多機能なフレームワークのもう 1 つの特徴として、 ポータルでユーザーおよびユーザーの役割に基づいて登録されているコンテンツを提供する「コンテンツ・スポット」を使用して、ユーザーのポータル環境をパーソナライズする機能があります。

カスタマイズ

ポータルをカスタマイズすることは、IBM WebSphere Portal の主な目的の 1 つです。 ページのコンテンツやレイアウトをカスタマイズするためのユーザー向けのポートレットやアドミニストレーター向けのポートレットが用意されています。 さらに、それぞれのサイト訪問者のニーズや関心に従って、特定分野の専門家がコンテンツをパーソナライズするためのツールもあります。

ページのカスタマイズ

ユーザーは 1 つ以上のカスタム・ページを作成して、ほかのページからそれぞれのページにアクセスできます。1 つのページには、特定の目的のために編成された、ページのグループを含むことができます。 各ページには、さまざまなポートレットのセットを作成できます。 ユーザーは、それぞれの権限に基づいて、 スキンとページ・レイアウトを使用して、自分のページの外観と雰囲気を変更できます。 また、ページのナビゲーション階層はツリー・ベースであり、ページのネストがいかに深くとも対応できます。

ユーザーまたはアドミニストレーターは、各ページのコンテンツをセットアップすることができます。 アドミニストレーターは、特定のポートレットを必須ポートレットとして指定できます。 ユーザーはこれらの必須ポートレットをページ上で移動したり削除したりすることはできません。 それぞれのページに独自の色体系と列レイアウトを設定できます。

権限のカスケード

アドミニストレーターは、他のアドミニストレーターまたはユーザーに対して、 ページまたはページの一部をカスタマイズする権限を付与したり、取り消したりすることができます。 アドミニストレーターは、ユーザーのページ編集権限を決定できます。 アドミニストレーターは、他のアドミニストレーターがページおよびそのコンテンツに持っている編集権限をコントロールできます。 これは、 組織がポリシーを適用し、整合性を確保して、中央で管理されたコンテンツで地域固有のポータルを作成できるようにすることを目的としています。 例を用いて、このコントロールを分かりやすく説明します。

1 人目のアドミニストレーターが、ページを 3 つの列から構成することを指定し、 他のアドミニストレーターがこの列のレイアウトを変更することを認めないことにするとします。 1 人目のアドミニストレーターよりも持っている権限が少ない 2 人目のアドミニストレーターは、 列のレイアウトを変更することはできませんが、ポートレットを列に追加することはできます。 以下の図に、3 列に分割されたページを示します。 アドミニストレーターは、これらの列にポートレットを追加することができます。

ページの領域を示すこのグラフィックの説明が、このトピックで提供されています。

2 人目のアドミニストレーターは、列 1 に株式ポートレットを追加し、 列 2 に社内ニュース・ポートレットを追加します。 このアドミニストレーターは、誰でもこれらのポートレットを使用できるが、 ポートレットを除去することはできないようにする必要があります。 ただし、アドミニストレーターは列にポートレットを追加することができます。 したがって、ポートレットはロックされ、権限の少ない他のアドミニストレーターは、 このポートレットを除去することができません。 以下の図に、アドミニストレーター間での権限のカスケードの様子を示します。

ページのカスケードを示すこのグラフィックの説明が、このトピックで提供されています。

スキンとテーマ

WebSphere Portal は、HTML、カスケード・スタイルシート、イメージ、およびその他の標準 Web 設計成果物を使用して、ページの「外観」を定義します。 Java Server Pages (JSP) および他のサーバー・サイドの動的技法を使用してサイトの「外観」を定義に役立てることもできます。 エレメントを追加または変更すると、WebSphere Portal の外観を制御することができます。例えば、会社固有のブランド・エレメントを追加したり、カラー・スキームや表示スタイルを変更したりできます。 色体系やスキンの定義では、各テーマに複数のスキン、ブランド・エレメントを追加したり、ナビゲーション・スタイル、 ブラウザーから独立した動的カスケード・スタイルシートなどを利用できます。

スキンとテーマは、製品全体だけではなく、ページにも適用できます。 ポートレットにも個別に異なるスキンを適用できるため、 ユーザーのニーズに応じてポータルの外観を微調整できます。 ページごとに異なるテーマを使用すると、単一のインストールで多数の仮想ポータルを表示できます。

テーマとスキンを示すこのグラフィックの説明が、このトピックで定義されています。

ブランド・エレメント

マストヘッド、ナビゲーション領域、グラフィックス、ポートレットのタイトル領域、 スタイルシートなどの WebSphere Portal の表示エレメントをすべて変更して、 WebSphere Portal の外観をカスタマイズできます。 JPEG、GIF、CSS、JSP ファイルなどの標準ファイル・フォーマットを使用して、 外観とレイアウトを定義できます。

コンポーネントのインストール・フォルダーの構造に、「skin」フォルダーと「theme」フォルダーが含まれています。 各フォルダーには、「html」、「wml」、および「chtml」というフォルダーが含まれています。 これらのフォルダーには、ホーム・ページの基本構造、カラー・スキーム、およびポートレットの装飾などを定義するためのほとんどのファイルが含まれています。 ポータル・デザイナーは、これらのフォルダーをコピーして、そのコンテンツを変更すると「 外観と雰囲気」をカスタマイズできます。 テーマ管理ポートレットに、新しいファイルが登録されます。

ポートレット・レイアウトの変更

ドラッグ・アンド・ドロップ機能を使用して、ページ上の個々のポートレットの配置を変更できます。 ページ上のポートレットを再配置するには、ポートレットのタイトル・バーをクリックしてから、そのポートレットをページ上の新しい場所にドラッグします。 「ポートレット・パレット」からページにポートレットをドラッグして、 ポートレットをページに追加し、短時間で簡単にカスタマイズを行うことも可能です。

Personalization

Personalization コンポーネントは、 ユーザーのプロファイル内の情報とビジネス・ロジックに基づいて、 ユーザー向けのコンテンツを選択します。 Personalization 機能により、特定分野の専門家は、 各サイト訪問者のニーズや関心に適したコンテンツを選択できます。 これらの Web ベースのツールにより、 企業はビジネスや特定分野の専門家が作成したコンテンツを迅速かつ簡単に活用することができます。 Personalization には 3 つの基本的な Personalization コンポーネントが組み込まれています。

  • ユーザー・プロファイル: ユーザー属性などのサイトのユーザーに関する情報です。

  • コンテンツ・モデル: 製品説明、記事、その他の情報など、コンテンツに関する属性を定義します。

  • マッチング・テクノロジー: ユーザーと目的のコンテンツを一致させるエンジンです。 フィルタリング、ルール、レコメンデーション・エンジン、またはこれら 3 つの組み合わせが組み込まれています。

Personalization およびWebSphere Portal のコンポーネントは、 共通ユーザー・プロファイルとコンテンツ・モデルを共用します。 モデルは、WebSphere リソース・フレームワーク・インターフェース・クラスをベースにしています。 つまり、 Personalization ルールをポートレットに簡単に追加し、ユーザー登録された WebSphere Portal に対して、 選択したコンテンツを設定することができます。

Personalization は、サイト訪問者をセグメントに分類し、 関連コンテンツのターゲットを各セグメントに設定します。 ビジネス・エキスパートは、Web ベースのツールを使用して、ユーザーの分類とコンテンツを選択するためのルールを作成します。

Personalization には、 協調フィルタリング機能があるレコメンデーション・エンジンも組み込まれています。 協調フィルタリング機能は、 統計技法を使用して、同種の関心事や行動を元にユーザー・グループを識別します。 グループの他のメンバーの関心事に従って、特定のユーザーの関心事を推論します。

新規キャンペーン管理ツールも Personalization に組み込まれています。 キャンペーン は、 ビジネス目標を達成するためのビジネス・ルール・セットです。例えば、株式購入計画への申し込みを従業員に呼びかけるキャンペーンを HR 管理者が実施するとします。 HR 管理者は、 このビジネス目標を達成するために表示するルール・セットを定義します。キャンペーンには、開始日と終了日があり、E メールまたは Web ページを使用します。 複数のキャンペーンを同時に実行して優先順位を付けることができます。

暗黙のプロファイル・サービスにより、サイト訪問者のアクションについてリアルタイム情報を収集し、 そのデータを使用して Personalization ビジネス・ルールを構成できます。 サイトおよび Personalization 戦略の効果を解析するために、 サーバーは、サイトの所有者向けのレポートを作成します。これにより会社は目標の達成に向けて、ビジネス・ルールやキャンペーンの効率を評価できます。

ユニバーサル・アクセス

ページ・テンプレート、テーマ、スキン、およびポートレット・レンダリングなどのシステムは、 国際化および障害者対応のユーザー補助について完全対応しています。 国際的なアクセスを受けるポータルについては、対象となるブラウザーとその言語および国設定をもとに、WebSphere Portal が適当な JSP ページを検索および選択します。

合理化されたサイト作成

IBM WebSphere Portal には事前構築済みのサンプル・インターネットおよびイントラネット Web サイトが付属しており、これらのサイトを探索して、さまざまなタイプのコンテンツのオーサリングや管理について学習したり、独自のポータルの開発を合理化するためのテンプレートとして使用したりできます。新規サイト・ウィザードを使用して、独自のポータル・サイトを生成することもできます。

サンプル・サイト

サンプルのイントラネットおよびインターネット・サイトは、WebSphere Portal のインストール時に自動的にインストールされるわけではありませんが、インストールが完了した後、ポータル・データベース、ユーザー・レジストリー、コンテキスト・ルート、またはセキュリティーのいずれかを構成する前に configure-express タスクを実行することにより、それらのサンプル・サイトを追加できます。 詳しくは、ご使用の特定のプラットフォーム上でのスタンドアロン・サーバーまたはクラスター・サーバーのセットアップに関する説明を参照してください。

サンプルのイントラネットおよびインターネット・サイトにアクセスするには、メイン・ポータル・バナーの「詳細表示」メニューを使用するか、ブラウザーで該当する URL を開きます。
  • イントラネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/intranet
  • インターネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/internet

独自の従業員サイトを作成する開始点として、イントラネット・サイト・テンプレートを使用します。「ホーム」、「作業 (Work)」、および「リソース (Resources)」ページは、現状のまま使用したりカスタマイズしたりできるプレースホルダー・コンテンツでシードされます。 使いやすいリスト・ポートレットにより、アナウンス、ニュース、イベント、FAQ、およびリンクを編成して管理できます。

イントラネット・サイト・グラフィックの説明が、このトピックで提供されます。

インターネット・サイト・テンプレートを使用して、カスタマーが製品のオファリング、マーケティング・プロモーション、および会社ニュースについて学習できる Web サイトの構築を迅速に開始できます。

インターネット・サイト・グラフィックの説明が、このトピックで提供されます。

さらにその他のコンテンツ・サンプルが IBM WebSphere Portal Business Solutions Catalog で入手できます。

ポータル・サイトのオンデマンド作成

「新規サイト・ウィザード」を使用して、独自のサイトを生成します。ポータル開発のスキルや管理者からの支援は必要ありません。使用可能なサンプルからサイト・テンプレートを選択し、ご希望の外観を選択してから、残りの作業をウィザードに行わせるだけです。

このウィザードは、新しいサイトを仮想ポータルとして自動的に作成します。しかし、管理者および開発者は、このウィザードを拡張して不特定型のポータル・サイトを作成できます。ポータル開発者は、カスタム・サイト・テンプレートを作成してからウィザードに追加することにより、「新規サイト・ウィザード」を拡張することもできます。

「新規サイト・ウィザード」は、IBM WebSphere Portal Business Solutions Catalog からダウンロードします。パッケージのコンテンツにはポートレット .war (Web Application Archive) ファイル、サポート・ファイルとディレクトリー、および .pdf ファイル形式の詳細な指示が含まれています。ウィザードのデプロイ後に、ユーザーがアクセスできるページにポートレットを追加する必要があります。詳しくは、ウィザードに付属の .pdf ファイルを参照してください。

「新規サイト・ウィザード」画面。この図について詳しくは、このトピックのテキストを参照してください。

ポートレット

ポートレットは、IBM WebSphere Portal の中心的なパーツです。 ポートレットは、 個別に開発、デプロイ、管理、および表示される小さいアプリケーションです。 アドミニストレーターとユーザーは、ポートレットを選択および配列して、個別設定されたページを作成し、Web ページをカスタマイズできます。

WebSphere Portal には、多数の標準ポートレットが付属しています。 ダウンロード可能な最新のポートレットなどのポートレットの最新情報については、「IBM WebSphere Portal Business Solutions Catalog」を参照してください。 また、カスタム・ポートレットの作成について詳しくは、『ポートレットの開発』を参照してください。

ポートレット・アプリケーション

ポートレットは、既存の単純な Web コンテンツとは異なります。 ポートレットは、標準のモデル表示コントローラー設計を 使用した 1 つの完全なアプリケーションです。 ポートレットには複数の状態と表示モードのほか、イベント機能やメッセージング機能があります。

ポートレットは、Application Server 上でサーブレットが動作するのと同じように、Application Server 内で動作しますが、WebSphere Portal サーバーによって複数のポートレットが集約され、1 つの完全な Web ページにまとめられます。 ポートレット・コンテナーは ランタイム環境を提供し、ここでポートレットのインスタンス化、使用、そして最後に破棄が行われます。 ポートレットは、ユーザー・プロファイル情報へのアクセス、ウィンドウおよびアクション・イベントへの参加、 他のポートレットとの通信、リモート・コンテンツへのアクセス、クリデンシャルの検索、および永続データの保管などにおいて、WebSphere Portal インフラストラクチャーに依存します。

一般的に、ポートレットはサーブレットよりも動的に管理します。 例えば、WebSphere Portal コンポーネントを実行中に、いくつ かのポートレットからなるポートレット・アプリケーションをインストールしたり削除したりできます。 実稼働環境の場合でも、WebSphere Portal を実行中に、アドミニストレーターはポートレットの設定値やアクセス権を変更できます。

ポートレットの各モードでは、ポートレットが必要とするタスクに応じて、異なるユーザー・インターフェースを表示できます。 ポートレットにはいくつかの表示モードがあり、ポートレット・タイトル・バー上のアイコン (「表示」、「ヘルプ」、「編集」、「構成」、「共用設定の編集」) を使用して呼び出すことができます。

ポートレットは、最初は表示モードで表示されます。ユーザーがポートレットを使用すると、フォームと応答、エラー・メッセージ、その他のアプリケーション固有の状態など、一連のビュー状態をポートレットに表示できます。「ヘルプ」モードでは、ユーザーにヘルプが提供されます。 ユーザーは「編集」モードでポートレットの設定を変更できます。例えば、Weather ポートレットでは、ユーザーが場所を指定するための「編集」ページが表示されます。 「編集」モードにアクセスするには、ユーザーは WebSphere Portal にログインする必要があります。「構成」モードではすべてのポートレット・インスタンスに関するポートレットのデフォルトの外観が変更され、「共用設定の編集」では特定のページ上のポートレットの外観が変更されます。

それぞれのポートレット・モードの表示には、標準、最大、最小を選択できます。 ポートレットを最大化すると、ポートレットはページ全体に表示されるので、その他のポートレットは表示されません。 ポートレットを最小化すると、デフォルトでは、ページ上にポートレット・タイトル・バーだけが表示されます。

ポートレット API

Java Portlet Specification は、ポータル環境で実行されるポートレットの集約、Personalization、 プレゼンテーション、およびセキュリティーの要件を指定したものです。 WebSphere Portal は、ポートレット規格 JSR 168 および JSR 286 を両方ともサポートしています。 標準ポートレット API について詳しくは、標準ポートレット API に関するトピックを参照してください。

ポートレット通信

WebSphere Portal を使用すると、ポートレットが互いに通信できます。 ポートレット通信を使用して、ポートレット間でデータを交換できます。 したがって、ポータルが使いやすくなります。

ポータルは、JSR 286 仕様の定義どおりにイベントをサポートします。 管理者は、ポータル・ユーザー・インターフェースを使用してポートレットをワイヤリングできます。

例えば、1 つのポートレットでアカウントに関する情報を表示し、2 番目のポートレットでは、そのうちの 1 つのアカウントについて過去 30 日分のトランザクションに関する情報を表示することができます。これをするには、トランザクション・ポートレットがトランザクション詳細を表示するときに、該当のアカウント情報を取得する必要があります。この操作は、JSR 286 仕様の記述どおりにイベントを使用して、2 つのポートレットがお互いに通信することで達成されます。 この例では、アカウント・ポートレットがポートレット記述子内で公開イベントを定義します。 トランザクション・ポートレットは、ポートレット記述子内で処理イベントとしてこのイベントを定義します。 ポータル・ユーザー・インターフェースを使用すると、これらの 2 つのポートレットを一緒にワイヤリングできるようになります。 ワイヤリング後、アカウント・ポートレットがイベントをスローすると、トランザクション・ポートレットはこのイベントを受け取り、このアカウントのトランザクションに関する情報を表示できます。

ポートレット・サービス

ポートレット・サービスは、各ポートレットに共通機能を提供する場合に使用します。 各ポートレット・サービスには、提供する機能用の独自のサービス固有のインターフェースがあります。WebSphere Portal では、標準ポートレット用のポートレット・サービスがサポートされています。 標準ポートレットでは、JNDI 検索を使用して PortletServiceHome オブジェクトを検索します。このオブジェクトは、ポートレット・サービス実装を検索する場合に使用します。 ポートレット・サービスは、ポートレット内部のコードによってのみ起動されます。 ポータル内のポートレット・サービスについて詳しくは、ポートレット・サービスに関するトピックを参照してください。

ポートレット・アプリケーションの作成とカスタマイズ

WebSphere Portlet Factory は、WebSphere Portal に付属しており、コーディングなしのポートレット開発プロセスを詰め込んだ、厳選したビルダーを備えています。 WebSphere Portlet Factory の RAD テクノロジーを使用すると、従来の J2EE 開発方式を使用するより、ポートレットの作成時間を 40 % から 70 % 速くすることができます。 WebSphere Portlet Factory を使用すると、ドラッグ・アンド・ドロップ、インライン編集、先行入力検索、インテリジェント・ページ・リフレッシュ機能などのフィーチャーを使用して、サービス指向のカスタム・ポートレットや、高機能の対話式 Web 2.0 スタイルのアプリケーションを短時間で開発してデプロイできます。WebSphere Portlet Factory は、高機能な事前構築済みコネクター・ライブラリーにより、さまざまな種類のパッケージ化エンタープライズ・アプリケーション、リポジトリー、データ・ソース (SAP、Siebel、PeopleSoft、Lotus Domino、Web、REST サービスを含む)、主要なリレーショナル・データベースからデータを統合して、操作可能データを価値の高いビジネス情報に変換します。ネイティブの WebSphere Portal 統合を使用して、リアルタイムに問題を簡単に解決できるようにするコラボレーション・フィーチャーが組み込まれた複合アプリケーションを作成できます。

開発者は、WebSphere Portlet Factory の特許である動的プロファイル機能を使用することによって、パーソナライゼーションにより簡単にポートレットをビジネス・ユーザー主導でカスタマイズできるようにすることができます。 さらに、ユーザーの役割や所在地などに基づいてポートレットのコンテンツが変化するような、ターゲットを絞った動的アプリケーションを作成できます。 WebSphere Portlet Factory を使用して構築されたアプリケーションを複数のランタイム環境にデプロイして、対象者に基づいて正しいユーザー・エクスペリエンスを提供できます (WebSphere Portal、Mashup Center、Lotus Notes および Expeditor、WebSphere Application Server を含む)。

WebSphere Portlet Factory アプリケーションは、JSR 168 および JSR 286 を含むポートレット規格に基づき、これに準拠する規格です。

ポータル・コンテンツのタグ付けおよびレーティング

ユーザーはポータル・コンテンツにタグ付けやレーティングを行うことができ、そのタグやレーティングを表示できます。 タグ付けやレーティングにより、ユーザーはポータル・コンテンツをより効率的に編成、分類、および検索することができます。 これには Web Content Management コンテンツやカスタム・コンテンツなど含まれます。 例えば、ユーザーはオンライン・ブック・ストアで本にタグ付けしたり、レーティングしたりすることができます。

注: デフォルトのポータル・インストール環境では、ページ・ビルダー のテーマのページのタグ付けおよびレーティングのみをサポートしています。 したがって、Portal テーマをデフォルトのサイト・テーマとして選択する場合は、タグ・センターが予期したように表示されない場合があります。
Portal ユーザーはポータルのコンテンツをタグ付けまたはレーティングすることができます。これには次のタイプのリソースが含まれます。
  • ページおよびポートレットなどのポータルのリソース
  • 記事や画像などの Web Content Management のリソース
  • カスタム・リソース。例えば、オンライン・ストアの品目やポートレット内のピクチャーなどが可能です。 管理者はこれらのカスタム・リソースにユーザーがタグ付けしたり、レーティングしたりすることができるように、これらをポータルに追加できます。
一般に、ポータル内で一意的に識別できるすべてのコンテンツに対してはタグ付けやレーティングができます。
ユーザーは次の目的のために、タグおよびレーティングを公開で、および私用で適用できます。
  • 公開のタグ付けおよびレーティングは、他のユーザーによるタグ付けおよびレーティングに基づいて、ユーザーがポータル・コンテンツを分類、評価、検索するのに役立ちます。
  • 私用のタグ付けおよびレーティングは、ユーザーが自身の個人的な方法を作成してポータル・コンテンツの分類、評価、検索を行うのに役立ちます。
ポータルではタグ付けおよびレーティングのために、2 つのユーザー・インターフェースが用意されています。
  • デフォルトのユーザー・インターフェース。これにより、ユーザーはリソースのタグ付けおよびレーティングを行い、複数のリソースのタグおよびレーティングを表示できます。
  • デフォルトのインターフェースの代わりに、インライン・ウィジェットを処理するユーザー・インターフェースも使用できます。 これは、各リソースのコンテキストで、個々のリソースのタグ付けおよびレーティングを表示します。 このユーザー・インターフェースはデフォルトで、ブログおよび Wiki で使用可能です。 管理者はこのユーザー・インターフェースを他のタイプのリソースに追加することもできます。
詳細として、ポータル・ユーザーは次のタスクを実行することができます。
  • タグの処理。
    • ポータル・コンテンツのタグ付け。ユーザーはポータル・コンテンツにタグを追加できます。例えば、タグ websphere を、IBM WebSphere 製品に関する情報を提供するページに適用することができます。ユーザーは、自分が付けたタグを削除できます。
    • タグおよび関連したポータル・コンテンツの表示。ユーザーは個々のポータル・リソースに付けたタグを、例えばデフォルトのタグ・ウィジェットおよびレーティング・ウィジェットを呼び出すことにより、表示できます。 また、ユーザーは選択されたタグの集約セットを処理することもできます。
      • ユーザーはタグ・クラウドを使用することにより、あるリソース・セットに付けたタグを表示できます。タグ・クラウドはタグをアルファベット順にリストします。異なるフォント・サイズは、タグがどれだけ頻繁に付けられたかを示します。 管理者がタグ・クラウドを構成した方法に応じて、リストはポータル全体にわたることも、特定の項目に限定することも可能です。例えば、ポータル・ページのリストや、ユーザーがタグをクリックしたページで入手可能な本のリストにすることができます。
      • タグ・クラウドはさまざまなビューをサポートしており、ユーザーはこれらのビューを切り替えることができます。 例えば、すべてのタグの表示、自分が付けたタグのみの表示、自分の私用タグの表示、一番新しく追加されたタグの表示、などを切り替えられます。
      • ユーザーは異なる表示モードを切り替えることができます。例えば、前述のようにクラウドでタグを表示したり、単純なリストで表示したりすることができます。
      • ユーザーはタグ・クラウドで表示されたタグを使用してコンテンツを検索できます。 ユーザーがタグをクリックすると、そのタグの付いたリソースのリストがポータルに表示されます。 そのようなリソースをクリックすると、ユーザーはそのリソースそのものにリダイレクトされます。 複数のタグをクリックすることもできます。その場合、リストには選択したすべてのタグが付いたリソースのみが表示されます。
      • ユーザーがリソースのリストを操作する場合に、タイトル、日付、レーティングなど、さまざまな基準でリストをソートできます。 この結果のリスト・ポートレットでも 2 つの表示モード、要約ビューと詳細ビューがサポートされています。
  • レーティングの処理。
    • ポータル・コンテンツのレーティング。
      • ユーザーは個々のリソースにレーティングを付けて、そのリソースを「好む」程度を示すことができます。 例えば、ユーザーが良い本に 4 のレーティングを与える場合があります。
      • ユーザーは自分が付けたレーティングを変更したり削除したりすることができます。 例えば、あるユーザーが前回付けたレーティングの 45 に更新することができます。
    • ユーザー自身や他のユーザーがポータル・コンテンツに付けたレーティングの表示。
管理者は次のタスクを実行できます。
  • 上記にリストした、ポータル・ユーザーが実行できるすべてのタスク。
  • ユーザーがタグ付けやレーティングをできるコンテンツの追加 (ブック・ストアの本など)。
  • ユーザーがコンテンツのタグ付けやレーティングを行うためのアクセス権限の割り当て。
  • タグ・クラウドの構成。デフォルトで、タグ・クラウドはポータル全体のリソースに付けられたすべてのタグを表示します。 管理者は必要に応じてタグ・クラウドをポータル・ページやポータル・テーマに追加して、それらを構成することができます。 例えば、タグ・クラウドを制限して、あるカテゴリー (ポートレットなど) のリソースに割り当てられたタグのみを表示するようにできます。 ユーザーがそのタグ・クラウドからタグをクリックすると、結果リストにはリソースのみ (この場合はポートレット) が表示されます。
  • タグを別のポータル・システムに移動 (例えばステージングのためや、マイグレーション時)。
  • タグ付けおよびレーティングについての基本的な統計の取得。例えば、特定のポータル・ページのタグおよびタグ数を入手したり、特定のユーザーが付けたすべてのタグを取得できます。 さらに詳細な統計を取得するために照会を作成したり、それらを視覚化するためのユーザー・インターフェースを作成したりすることができます。
開発者は次のタスクを実行できます。
  • Java Model API や REST API を使用するカスタム・ユーザー・インターフェースを作成することにより、ポータルのタグ付けおよびレーティング機能を拡張。
  • タグ付けおよびレーティングに関する統計を取得するための照会の作成、およびそれらの統計を視覚化するためのユーザー・インターフェースの作成。
  • フィルターの使用可能化または使用不可化。例えば、ユーザーがタグとして望ましくない単語を使用しないようにします。 デフォルトで、ポータルにはブラックリスト・フィルターおよびホワイトリスト・フィルターが用意されています。
注: ポータルおよびユーザー・グループによっては、管理者または開発者がポータル・ユーザーに対して、タグ付けおよびレーティングに関するエンド・ユーザー向け資料の作成を検討する場合があります。

ブログおよび Wiki

ブログおよび Wiki 機能を Web サイトに追加するために、プリインストールされた Web コンテンツ・ライブラリーのセットが提供されています。 ブログ、ブログ・ライブラリー、および Wiki を使用して、コミュニティーの能力を活用し、作業する方法を変更します。

ブログは、単一のトピックに関するアイデアを生み出したい場合に使用できる優れたツールです。 ブログは、自分個人の作業に使用したり、より大きなチームから単一の概念に関するフィードバックを得るために使用したりできます。 ブログ・ライブラリーは、ブログを次のレベルに引き上げます。ブログ・ライブラリーを使用することにより、トピックごとにブログを作成する代わりに、一元化された場所で複数のトピックを追跡することができます。 さらに、Wiki は、コンテンツをオーサリングするためのもう 1 つの代替方法を提供します。 イメージおよびリンクの挿入を含む、単純なインライン編集によって、Wiki のオーサリングは迅速かつ簡単になります。また、ブログおよび Wiki のコンテンツにタグ付けおよびレーティングを行うこともできます。

ブログ、ブログ・ライブラリー、および Wiki は、IBM Lotus Web Content Management で提供されるテンプレート・ライブラリーを使用します。各ブログ、ブログ・ライブラリー、および Wiki には独自のライブラリーが存在します。 これらのコンポーネントで提供されるページ階層は、Web Content Management テンプレート・ライブラリーで定義される一般的なページ階層です。

アプリケーションの統合

ポータルを使用すると、企業内に存在するコンテンツ、データ、サービスなどにアクセスできます。 これらのサービスには、 所定の、あらかじめ定義されたコネクターおよびポートレットと、 コネクターおよびポートレットを追加作成するためのツールが含まれます。

エンタープライズ・リソース・プランニング (ERP) およびカスタマー・リレーションシップ・マネージメント (CRM) の 2 つのシステムはポートレットとして最適の対策となります。 効率の良い、個別のアクセスを使用してさまざまな機能にアクセスできますので、ポータルでは納得のいく投資回収を見込めます。IBM では、Java Connector Architecture (JCA) を使用して、エンタープライズ・アプリケーションへのコネクターを提供しています。

標準 Java コネクター

JCA は、Java 2 Enterprise Edition (J2EE) アプリケーションをリレーショナル・データベース以外のエンタープライズ情報システムに統合するための標準アーキテクチャーです。 呼び出す機能の識別、入力データの指定、および出力データの処理について、それぞれのシステムがネイティブの API を提供します。 JCA の目的は、こうした機能をコード化するための独立した API を提供することです。

さらに JCA は、標準的な Service Provider Interface (SPI) を定義して、 アプリケーション・サーバーとトランザクション・リソース・マネージャーのトランザクション、セキュリティー、および接続管理機能を統合します。このため、JCA では、エンタープライズ・アプリケーション・システムへの接続管理、トランザクション、およびセキュア・アクセスについて、規格をベースにしたアプローチを利用しています。 IBM JCA コネクターは、 SAP、PeopleSoft、J.D. Edwards、Oracle Enterprise Edition CICS、 IMS、および Host-on-Demand などのシステムへのアクセスを提供します。 IBM は CrossWorlds の買収により、さらに多くのシステムに対応する JCA コネクターの開発および統合を計画しています。

Rational Application Developer は、JCA コネクター、Web サービス、 およびマイクロフローを使用するアプリケーション用の完全な開発および単体テスト環境を提供します。Rational Application Developer ツールには、Web Service Definition Language (WSDL)、 開発者バージョンのコネクター、Web Services Invocation Framework (WSIF)、 およびマイクロフロー・エンジンに対するサポートが含まれています。

コラボレーション

IBM WebSphere Portal のコラボレーション機能は、Lotus Domino および Extended Products ポートレット を介して提供されます。 Lotus Domino and Extended Products には、Lotus Domino Enterprise Server と IBM Lotus Sametime があります。

ポートレットは、Lotus Domino Server 製品を WebSphere Portal に完全に統合する際に使用するメカニズムです。Lotus Lotus Domino および Extended Products ポートレット は、ユーザー認識を用いるオンライン・ディレクトリーと、オンライン会議を管理するための統合ツールを提供します。これらすべてのコラボレーション機能は、ビジネス目的達成のために組織の社員が協働し、情報をオンラインで共用しやすくします。コラボレーション・ポータルにより、 組織の反応性、革新性、能力、および作業効率を改善できます。

IBM Lotus Domino および IBM Lotus Sametime のサポートされるバージョンについては、WebSphere Portal の詳細なシステム要件を参照してください。

コラボレーション・ポートレット

Lotus Domino および Extended Products ポートレットのすべての事例が、「コラボレーション」ページおよび「メッセージング」ページに提供されています。ポートレットは、WebSphere Portal ととも にインストールされ、自動的にデプロイされるため、アドミニストレーターが、サーバーの数やその他の構成タスクを行うだけで、 ユーザーは一連の統合されたコラボレーション・アプリケーションを使用することができます。

Lotus Domino および Extended Products ポートレット には以下が含まれます。

  • iNotes®
  • Sametime コンタクト・リスト
  • Lotus Notes ビュー
  • ピープル・ファインダー
  • 在席リスト

在籍確認

ユーザーは、ユーザー・カードを表示することにより、登録ユーザーの一般的な名刺情報 (連絡先など) を見ることができます。ユーザー・カードは、Lotus Domino および Sametime 統合、複合アプリケーション、パーソナライゼーション、Web コンテンツ・オーサリングなどを含む幅広いポータル・コンポーネントを通じて使用可能です。 ユーザー・カードを表示するには、アクティブな (下線付きの) ユーザー名の上にカーソルを移動し、「クリックしてユーザー・カードを表示」を選択します。

ポータル構成でLotus Sametime を使用可能にすると、ユーザーは、 インスタント・メッセージングおよび e ミーティングによるアプリケーション共用を含め、 ユーザー認識機能の完全なセットを使用して作業することができます。 ユーザー名は、動的オンライン状況標識とともに認識 されます。「プロファイル」をクリックすると、ユーザーに関する完全な情報が表示されます。追加のアクションには以下のようなものがあります。

  • メールの送信
  • チャット
  • Sametime コンタクトとして追加

ポータル構成で Lotus Sametime を使用可能にしないことを選択すると、ユーザー認識機能が制限されます。個人の名前はハイパーリンクとして表示されますが、それぞれの名前の横にユーザー認識アイコンは付きません。また、ユーザー・カード上で実行可能なアクションは、WebSphere Portal にネイティブなもののみに限定されます。

ユーザー補助機能

ユーザー補助機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるように サポートします。

このバージョンの IBM WebSphere Portal は、以下をサポートしています。

  • コンソール・モード というコマンド行インターフェースによるインストールをサポート。このインストールは、グラフィカル・ユーザー・インターフェースを使用したインストールと同等のユーザー補助です。
  • スクリーン・リーダーおよび画面拡大機能で一般的に使用されるインターフェースをサポート (Windows のみ)
  • 画面の表示内容を聞き取るために、スクリーン・リーダー・ソフトウェアおよびディジタル音声シンセサイザーの使用をサポート
  • キーボードのみを使用して操作可能
  • 時刻指定応答を完了する時間をさらに要求することが可能
  • カラー、コントラスト、フォント・サイズなどの表示属性のカスタマイズをサポート
  • カラーとは関係なく、すべての情報を伝達
  • 代替入出力デバイスの接続をサポート
  • 音声情報の代替手段をサポート
  • 調整可能なボリューム制御をサポート
  • てんかん発作を誘発する可能性のあるレートで画面が明滅しない
  • 利用できるフォーマットでドキュメンテーションを提供
注: スクリーン・リーダーを使用して WebSphere Portal を表示する際に最善の結果を得るには、Freedom Scientific JAWS 11 以上と Firefox 3.5 以上を併用してください。
ユーザー補助を強化するため、資料に、次のような機能が含まれています。
  • すべての資料は、スクリーン・リーダー・ソフトウェア・テクノロジーの適用の可能性が最大となる HTML 形式で入手可能。
  • 資料内のすべてのイメージは、視覚障害のあるユーザーがイメージの内容を理解できるように、代替テキストと共に提供される。

該当する場合は、特定の製品機能のドキュメンテーションに、ユーザー補助に関する追加情報が含まれています。

ユーザー補助に対する IBM のコミットメントについて詳しくは、IBM Human Ability and Accessibility Centerを参照してください。

非推奨の機能

IBM WebSphere Portal の旧バージョンで使用できたものの、このバージョンまたは今後のバージョンでは使用できない機能についての注記です。

準備が整い次第、非推奨の機能からの移行に役立つ、追加の情報へのリンクが提供されます。

Exchange、Lotus Domino、および POP3 が、Common Mail Portlet でサポートされるプロトコルではなくなりました。

これまで Exchange で CPP を使用していた場合は、Exchange のポートレットを使用できるようになりました。

これまで Lotus Domino で CPP を使用していた場合は、iNotes ポートレットを使用できるようになりました。

RSS ポートレットおよび IBM フィード・リーダー・ポートレットは出荷されなくなりました。

これまで RSS ポートレットまたは IBM フィード・リーダー・ポートレットを使用していた場合は、IBM Syndicated Feed Portlet for WebSphere Portal を使用できます。代わりに、RSS ポートレットおよび IBM フィード・リーダー・ポートレットを IBM WebSphere Portal Business Solutions Catalog からダウンロードできます。

Common Calendar ポートレットが、同梱されなくなりました。

これまで Exchange で CPP を使用していた場合は、Exchange のポートレットを使用できるようになりました。

これまで Lotus Domino で CPP を使用していた場合は、iNotes ポートレットを使用できるようになりました。

Document Manager
WebSphere Portal のこのバージョンでは、Document Manager を使用できなくなりました。 文書ライブラリーを引き続き使用する必要がある場合は、その文書ライブラリーを IBM Lotus Quickr サーバーに移動する必要があります。詳しくは、WebSphere Portal Best Practices Wiki を参照してください。
複合アプリケーションのワークフロー
このバージョンでは、複合アプリケーションのワークフローを使用できなくなりました。
コラボレーション・ポートレット
以下のコラボレーション・ポートレットは、WebSphere Portal に含まれなくなりました。
  • My Lotus QuickPlaces
  • インライン QuickPlace
  • Lotus Domino Document Manager
  • Lotus Web Conferencing
注: Lotus QuickPlaces は、IBM WebSphere Portal Business Solutions Catalog からダウンロードできます。
レガシー・サンプル・ポートレット
以下のレガシー・サンプル・ポートレットは提供されなくなりました。
  • SPFLegacyBlank.war
  • SPFLegacyClock.war
  • SPFLegacyCommandManager.war
  • SPFLegacyEditMode.war
  • SPFLegacyFileUpload.war
  • SPFLegacyLookupAction.war
  • SPFLegacyMailReader.war
  • SPFLegacyMultipleServletContexts.war
  • SPFLegacyStockQuote.war
  • SPFLegacyTiles.war
  • SPFLegacyTransformation.war
Microsoft Exchange 2000 ポートレット・アプリケーション
Microsoft Exchange 2000 ポートレット・アプリケーションは含まれなくなりました。 このポートレット・アプリケーションは、次のポートレットを含んでいます。
  • MS Exchange 2000 Mail ポートレット
  • MS Exchange 2000 Calendar ポートレット
  • MS Exchange 2000 Tasks ポートレット
  • MS Exchange 2000 Contacts ポートレット
  • MS Exchange 2000 Notes ポートレット
トランスコーディング・テクノロジー
今まで WebSphere Portal に提供されていたトランスコーディング・テクノロジーは、このバージョンでは廃止されています。
ブラウザー・サポート
このバージョンでは、以下のブラウザーはサポートされなくなっています。
  • Mozilla
  • Netscape
ポータル・スクリプト・インターフェース用の JACL 構文
ポータル・スクリプト・インターフェース用の JACL 構文は、WebSphere Portal バージョン 6.1 で Jython 構文に置き換えられています。 JACL 構文は引き続きサポートされますが、このサポートは今後、廃止される予定です。
専用ワイヤー API
専用ワイヤーを参照する WireModel 成果物は、WebSphere Portal バージョン 6.1.0.1 以降推奨されなくなりました。
IBM ポートレット API の Web コンテンツ・ビューアー・ポートレット
バージョン 7.0 では、IBM ポートレット API に基づく Web コンテンツ・ビューアー・ポートレットは使用されなくなり、JSR 286 Web コンテンツ・ビューアー・ポートレットに置換されました。
IBM ポートレット API のリモート Web コンテンツ・ビューアー・ポートレット
バージョン 7.0 では、IBM ポートレット API に基づくリモート Web コンテンツ・ビューアー・ポートレットは使用されなくなりました。 Web Content Management がインストールされていないポータル上に Web コンテンツを表示する場合は、WSRP および JSR 286 Web コンテンツ・ビューアーを使用します。Web コンテンツをバージョン 7.0 より前のリモート Web Content Management システムから表示する必要がある場合、引き続きリモート・サーバーから IBM API のリモート Web コンテンツ・ビューアー・ポートレットを使用できます。

インストール

IBM WebSphere Portal は、機能の検査とテストができる PoC (概念検証) から使い勝手がよく拡張が容易な実稼働環境まで、柔軟なデプロイメント・オプションを提供します。ハードウェアおよびソフトウェア要件、高可用性、拡張容易性、サポートされているトポロジーなどについてさらに知るため、計画情報をレビューしてください。オペレーティング・システムを選択してから、業務上の必要を最もよく反映できるインストール・パターンを選択してください。

重要: WebSphere Portal のインストール後に、マッシュアップ統合の使用を計画している場合は、「マッシュアップ統合」 > 「ポータルおよびマッシュアップの構成」 > 「ポータルでのマッシュアップ統合の使用可能化」のトピックにリストされている deploy-portal-mashup-ui タスクを実行する必要があります。

WebSphere Portal をインストールするための計画

実稼働環境で IBM WebSphere Portal をインストールする前に、ハードウェアおよびソフトウェアの要件、可能なデータベース構成、セキュリティー・オプション、および LDAP サーバー・オプションを考慮する必要があります。 この重要なステップを省略すると、予期しない結果とコストの高い遅延が発生する可能性があります。

このタスクについて

システム要件

IBM WebSphere Portal をインストールする前に、ハードウェアとソフトウェアの要件を確認して、サポートされているバージョンの前提条件ソフトウェアと相互に必要なソフトウェア、および必須ハードウェアがあることを確認します。

システム要件の詳しい資料については、以下の URL を参照してください。
http://www.ibm.com/support/docview.wss?uid=swg27007791

リリース・ノート

既知の問題は、まとめてサポート・ページで説明されています。 サポート知識ベースへのリンクがインフォメーション・センター全体に組み込まれており、最新の情報を確実に得られるようにしています。 インストール・プロセスを開始する前に、IBM サポート・サイトを調べて、既知の制限事項または問題に関する最新情報を確認してください。 このリリースに関する最新の情報を検索するには、以下の動的照会を使用してください。

以下のリンクは、識別されている領域に関する技術情報の最新リストを返します。 所定のトピックの領域に関する技術情報が公開されていない場合は、リンクは技術情報を返さず、検索を詳細化するよう指示されます。

インストールおよび構成の問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSCPKQ9+SSC3QNP
マイグレーションの問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSCPKQB
データベース接続の問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSC3QNK
このリリースに関するすべての技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0

また、インフォメーション・センターから直接、サポート・サイトを検索できます。 IBM Support Web サイトにおける解決策の検索 のトピックを参照してください。

WebSphere Portal サポート・ステートメント

このサポート・ステートメントでは、IBM WebSphere Portal が正常に動作するために依存している各種製品に関して、「サポート」および「非サポート」の定義の改訂を提案しています。

概要

WebSphere Portal には、それが正常に動作するためのいくつかの付随製品が必須です。特に、Portal は WebSphere Application Server、データベース、ユーザー情報用のリポジトリー (一般には LDAP)、および特定のカスタマー要件に応じたその他の製品を必要とします。

新規リリースのテスト時には、開発は一般に、 これらの付随製品の所定のリストを使用して WebSphere Portal をテストします。これらの製品は、そのリリース用のハードウェア要件およびソフトウェア要件に関する文書で「サポート製品」として指定されています。

「サポート製品」のリストには、お客様が使用する必要があると考えられる構成をすべて記載できるわけではないので、一部のお客様からは、具体的に「サポートされる」として示されていない構成に対して提供されるサポートのレベルについて不安の声が寄せられています。本書は、依存製品をさまざまに組み合わせて使用している現在のリリースに対して一般的に期待できるサポート・レベルを説明することを目的としています。

注: この文書のステートメントは、WebSphere Portal に対して期待できる一般的なサポート・レベルを反映していますが、実際に提供される製品のサポートは、特定のサポート・オファリング、ライセンス、または IBM と交わされるその他の契約の条件によって決まります。ここでの内容を、WebSphere Portal に関する IBM ご使用条件または IBM と交わされるその他の契約の補足、変更、または置き換えと解釈しないでください。また、ここでの内容によって、そのような契約で発生すると考えられるサポートとは異なるレベルのサポートを提供する義務を IBM が負うものでもありません。

サポートのカテゴリー

WebSphere Portal に付随する製品のサポートには、3 つのカテゴリーがあります。 それは、「サポート製品」、「サポート製品の最新バージョンおよびリリース」、「非サポート製品」の 3 つです。 カテゴリーごとの定義およびサポート・ステートメントは以下のとおりです。

サポート製品
「サポート製品」とは、開発によってテストされ、WebSphere Portal で動作することが判明している (指定されたバージョン、リリース、および修正レベルにある) 製品です。

このカテゴリーの製品は、WebSphere Portal のご使用条件の条項ごとにサポートされます。PMR (問題管理レコード) は、WebSphere Portal ご使用条件の条件に従って IBM サポートによって受け入れられます。

サポート製品の最新バージョンおよびリリース
「サポート」バージョンの特定のバージョン、リリース、またはフィックスパック以外の多くの製品 (ハードウェア要件およびソフトウェア要件に関する文書で解説しています) は、IBM WebSphere 開発によって明示的にテストされていない場合がありますが、お客様の信頼性、機能、およびパフォーマンスの許容範囲内で動作するとお考えください。

このカテゴリーに該当するのは、通常、すでに「サポート製品」のカテゴリーに分類されている比較的新しいリリースまたは修正レベルの製品か、 WebSphere Portal がサポートする標準 API に準拠する製品 (LDAP サーバーなど) です。 例えば、オペレーティング・システムの最近の修正レベル、最初に「サポートされている」フィックスパック・レベルよりも新しい WebSphere Application Server (WAS) のフィックスパック、IBM Java (JVM) フィックスパック、DB2 の新規のフィックスパックまたはリリース、更新済みの LDAP サーバーなどがあります。

このカテゴリーに当てはまる製品には以下のサポートがあります。

IBM Directory Server または Lotus Domino LDAP、IBM DB2、IBM JDK (JVM)、および WebSphere Application Server などの IBM 製品の場合、WebSphere Portal は、WebSphere Portal がその機能を得るために依存しているインターフェースまたはその他の基本サポートからわずかしか変更されていないフィックスパック、リリース、およびバージョンの更新をフルサポートします。WebSphere Portal が対応できない、これらの製品の 1 つの最新リリースが出荷された場合は、『非サポート製品』というタイトルの次のセクションで説明しているように、そのことが示されます。 WebSphere Portal がデータベース製品または LDAP 製品への更新をサポートするためには、WebSphere Application Server もその更新をサポートする必要があります。

IBM 以外の製品の場合、サポート・チームは、商業的に妥当と思われる作業でこのカテゴリーの製品をサポートします。サポートは、これらの未テスト製品を使用している、該当するリリースの問題報告 (PMR) を受け入れます。 サポートが、報告された問題を「サポート」バージョンの製品を使用して再現できる場合は、その問題を修正します。

サポートは、問題の生じている「サポート」バージョンの製品を使用して問題を再現できず、 未テスト・バージョンの該当する製品の問題を解決できない場合、その製品のサポート組織に依頼して解決を図ります。 IBM 以外の製品に対してこのプロセスを処理するには、程度はさまざまですが、お客様に何らかの形で協力していただく必要があります。

当該の未テスト製品のサポート組織が問題を解決できない場合、サポートは、当該の未テスト製品のそのバージョン、リリース、またはフィックスパック・レベルを「非サポート製品」とみなします。

非サポート製品
「非サポート製品」とは、WebSphere Portal では動作せず、そのためサポートされないことが判明している (指定されたバージョン、リリース、および修正レベルにある) 製品です。 製品がこのカテゴリーに含まれるのは、開発によって明示的にテストされた結果、または前のカスタマーの問題からそのことが発見された場合です。WebSphere Portal サポート・チームは、判明しているすべての「非サポート製品」のリストを WebSphere Portal リリースごとに管理しています。 このリストは、すべてのお客様が入手可能な techdoc として、Web で公開されています。

WebSphere Application Server には Web 上で参照できる類似のサポート・ステートメントがあります。

注: WebSphere Application Server は、特定のプラットフォームに関する IBM Java SDK の特別にカスタマイズされたビルドを使用しています。これらに対する更新は、WebSphere Application Server サポートから入手できます。

WebSphere Portal は、 基礎となる WebSphere Application Server の変更に左右されやすくなる可能性があります。 WebSphere Application Server のすべての必要な修正が、新しいフィックスパックに統合されるか、特にその保守レベルの暫定修正を適用することによって入手可能である限り、アプリケーション・サーバーの新しいフィックスパック・レベルへのアップグレードは耐用性が良好であり、推奨されています (WebSphere Application Server バージョン 7.0 から 7.0.x など)。ただし、WebSphere Application Server の 1 つのバージョンから次のバージョンへのアップグレード (例えば 6.1 から 7.0 へ) は、それがバージョンのマイグレーション作業の一部として実行されるのでない場合、大いに問題があり、「現場の」システムでは決して実行するべきではありません。 例えば、WebSphere Application Server バージョン 7.0 上にインストールされ、機能している WebSphere Portal バージョン 7.0 の既存のインスタンスは、WebSphere Application Server マイグレーション・ツールを 使用するだけで、WebSphere Application Server バージョン 7.1 に正常にマイグレーションできるというわけではありません。これを実行すると、システムが機能しない可能性があります。必要な場合には、そのようなシナリオの詳細について IBM WebSphere Portal サポートに相談してください。

LDAP サーバーのサポート

LDAP サポートには以下の 2 つのカテゴリーがあります。

完全にテストされサポートされている LDAP サーバーの場合:
WebSphere Portal の各リリースの 完全にテストされている LDAP サーバーのリストは、リリース毎に詳細なシステム要件内で文書化されています。システム要件について詳しくは、下記のリンクを参照してください。 WebSphere Portal サポートでは、テスト済みのディレクトリー・サーバーを使用して、該当する WebSphere Portal リリースの 問題の報告に応じます。これらの問題報告は、高い優先順位で処理されます。これらのディレクトリーでテストされる機能は、 ユーザーおよびグループ・オブジェクトの比較的単純な検索と取得機能などです。この範囲外の機能 (Active Directory の「グローバル・カタログ」機能など) は拡張機能と考えられ、WebSphere Portal ではテストされていません。WebSphere Portal サポートでは、お客様が LDAP プロバイダーと連絡を取り、これらの拡張機能に対する追加サポートを受けることができるよう支援します。
テスト済みでない、また部分的にサポートされている LDAP サーバーの場合:
一般的に、WebSphere Portal サポートでは、WebSphere Portal でテストされていないディレクトリー・サーバーのサポートに最善を尽くしています。 WebSphere Portal サポートでは、テストされていないディレクトリー・サーバーを使用して、該当する WebSphere Portal リリースの 問題の報告に応じます。 WebSphere Portal サポートが、テスト済み LDAP サーバーを使用して、報告された問題を再現できる場合は、スタッフが問題の修正を試みます。 サポート・チームがテスト済み LDAP サーバーで問題を再現できない場合は、 LDAP プロバイダーまでお問い合わせください。

外部セキュリティー・マネージャー (ESM) のサポート

ESM サポートには以下の 2 つのカテゴリーがあります。
完全にテストされサポートされている ESM ソフトウェアの場合:
WebSphere Portal の各リリースの 完全にテストされている ESM ソフトウェアのリストは、リリース毎に詳細なシステム要件内で文書化されています。システム要件について詳しくは、下記のリンクを参照してください。 WebSphere Portal サポートでは、テスト済みの ESM サーバーを使用して、該当する WebSphere Portal リリースの 問題の報告に応じます。これらの問題報告は、高い優先順位で処理されます。これらのソフトウェア製品でテストされる機能は、認証および許可などです。 この範囲外の機能 (ログインのカスタマイズ、参照、偽名の使用、ステップアップ認証機能など) は拡張機能と見なされ、WebSphere Portal ではテストされていません。 WebSphere Portal サポートでは、お客様が ESM プロバイダーと連絡を取り、これらの拡張機能に対する追加サポートを受けることができるよう支援します。
テスト済みでない、また部分的にサポートされている ESM サーバーの場合:
一般的に、WebSphere Portal サポートでは、認証でのみ ESM に依存する場合に、WebSphere Portal でテストされていない ESM サーバーのサポートに最善を尽くしています。 WebSphere Portal サポートでは、テストされていない ESM Trust Association Interceptor (TAI) 実装を使用して、該当する WebSphere Portal リリースの問題の報告に応じます。 WebSphere Portal サポートが、テスト済み ESM を使用して、報告された問題を再現できる場合は、スタッフが問題の修正を試みます。 サポート・チームがテスト済み ESM で問題を再現できない場合は、 ESM プロバイダーまでお問い合わせください。

ユーザー ID とパスワード

ユーザー ID とパスワードは、アクセスおよびセキュア・コンテンツを提供するためシステム全体で使用されるため、これらの文字制限について理解することは重要です。 ここで示す文字制限は、IBM WebSphere Portal アドミニストレーター、IBM WebSphere Application Server アドミニストレーター、データベース・アドミニストレーター、LDAP サーバー・アドミニストレーター、およびユーザー ID に適用されます。 データベースおよび LDAP サーバーには、ここに示す制限より厳密な制限を指定できます。 このため、制限についてはデータベースおよび LDAP サーバーの製品資料を確認する必要があります。 インストール・プロセス時にユーザー ID およびパスワードを正常に定義できなかった場合、インストールが失敗する可能性があります。 さらに、より厳密なユーザー ID およびパスワード要件を企業が指定している場合は、その要件にもに従う場合があります。

ユーザーがユーザーとしてサインアップする場合、あるいはアドミニストレーターにユーザー登録をしてもらう場合、ユーザー情報フォームに記入する必要があります。このフォームでは、サポートされていない可能性がある文字を入力しないでください。ユーザー情報フォームに入力可能な文字でも、ユーザー ID とパスワードは、ここで記述されている有効文字に制限されます。 「 名と姓 (氏名)」フィールドには、その他の文字も指定できます。 企業のポリシーがより厳密な場合、登録フォーム・ヘルプで、あるいはフォーム上の直接のインライン・ヘルプとして、その情報をユーザーに提供できます。

通常の環境では、有効なユーザー ID およびパスワードに以下の文字を含めることができます。
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。
重要: これらはすべて ASCII 文字です。 非 ASCII 文字はユーザー名にもパスワードにも使用できません。
注: (UNIX のみ) 一部のタスクでは、完全修飾のユーザー ID の入力が必要な場合があります。 完全修飾のユーザー ID にスペースが含まれている場合 (例: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com) は、 完全修飾のユーザー ID をコマンド行のフラグとしてではなく、プロパティー・ファイルに配置するか、または親のプロパティー・ファイルに配置する必要があります。 例えば、mysecurity.properties という親のプロパティー・ファイルを作成して完全修飾のユーザー ID を入力し、 次にタスク ./ConfigEngine.sh task_name -DparentProperties=/opt/mysecurity.properties を実行します。
注: (Windows のみ) 一部のタスクでは、完全修飾のユーザー ID の入力が必要な場合があります。 完全修飾のユーザー ID にスペースが含まれている場合 (例: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com) は、タスクを実行する前に、完全修飾ユーザー ID の前後を引用符で囲む必要があります (例: "cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com")。

下表は、ユーザー情報フォームおよびサポート文字に関する必須フィールドの説明です。

表 2. ユーザー情報で有効な文字および非サポート文字
ユーザー情報 有効文字 非サポート文字
ユーザー ID
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。

ASCII 文字のみが許可されています。

その他の制限事項: ユーザー ID には、user name のように、スペースを使用できません。ユーザー ID の長さは 200 文字を超えてはなりません。
インストール中にサポートされない文字を入力すると、どの文字が無効であるかを示すエラー・メッセージを受け取ります。 例えば、「管理ユーザー ID フィールドに特殊文字 [@] が見つかりました。 管理ユーザー ID を再入力してください。」などです。
重要: ユーザーおよびグループの管理ポートレットを使用してユーザーを作成するときに、サポートされない文字を入力すると、別のエラー・メッセージを受け取ります。
パスワード / パスワードの確認
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。

ウムラウトなどの発音記号および DBCS 文字は使用できません。

その他の制限事項: パスワードには、pass word のように、スペースを使用できません。パスワードの長さは 128 文字以内でなければなりません。
重要: パスワードに DBCS を含むサポートされない文字が使用されていると、ログインに失敗します。DBCS を含むパスワードを使用してユーザーが正常に登録されても、ログインには失敗します。

インストール中にサポートされない文字を入力すると、どの文字が無効であるかを示すエラー・メッセージを受け取ります。 例えば、「パスワード・フィールドに特殊文字 [@] が見つかりました。 パスワードを再入力してください。」などです。

すべての文字 該当なし
すべての文字 該当なし
注: user.UNIQUEID.charset パラメーターが ascii に設定されている場合、 上記の文字が該当します。unicode に設定されている場合は、標準 Java 文字定義が使用され、Java で文字または数字として認識されるすべての文字がデフォルトで許可されます。Portal のユーザー、グループ、およびパスワードの検証動作に影響するように変更できるパラメーターについて詳しくは、『ポータル構成サービス』リンクにある 「Puma 検証サービス 」セクションを参照してください。

オペレーティング・システムの準備

インストールが正常に完了するように、各操作には固有の準備が必要です。 インストール・ウィザードを続行する前に、ご使用のオペレーティング・システムが適切に準備され、すべての必要なハードウェアおよびソフトウェアの前提条件と相互前提条件が揃っていることを確認してください。

サーバー・トポロジー

トポロジー・ダイアグラムは、さまざまなユーザーとシステム負荷の要件をサポートするためにセットアップできるさまざまな構成を視覚化するのに役立ちます。 トポロジー・ダイアグラムは、基本的な構成の代表です。

単一サーバー・トポロジーでは、デモンストレーション、製品のお試し、または開発環境の目的で、単純なインストール済み環境が例示されています。 スタンドアロン・トポロジーでは、分散した構成が例示さています。 クラスター化トポロジーで例示されているハードウェア構成の方が堅固で負荷が集中しており、Web Content Management トポロジーではさまざまなハードウェア構成がさまざまなオーサリングやシステム負荷の要件をサポートする方法が例示されています。 容量および可用性を増大させるために、IBM WebSphere Application Server Network Deployment を使用して、複数のポータル・サーバーをクラスター化できます。IBM WebSphere Application Server Network Deployment では、ポータルは共通の構成を共有し、また負荷がすべてのクラスター・インスタンスに均等に配分されます。高可用性およびフェイルオーバー・トポロジーでは、複雑な実稼働環境での WebSphere Portal が例示されています。

単一サーバー・トポロジー

IBM WebSphere Portal の単一インスタンスは、十分な機能を持つアプリケーション・サーバー、および中規模から小規模のユーザー・コミュニティーにサービスを提供することのできる Web サイトを提供します。最初に、単一インスタンスは Derby をベースとした内部データベースを使用するよう構成されます。しかしこれは実動には適していないので、エンタープライズ・クラスのデータベース に置き換える必要があります。

単一サーバー・デプロイメントは、開発、テスト、デモンストレーション、および教育用、また上述のようなある種の小規模の実動サイトには理想的です。ただし、単一サーバーは Single Point of Failure があり、その容量、可用性、および能力を改善して障害状態から復旧するために、クラスターまたはサーバー・ファームに変換する必要があります。

下の図では説明されていないオプションの構成として、IBM WebSphere Application Server の HTTP プラグインを使用して Web サーバーを、テストまたは実動用の一般的なサーバー・デプロイメントの前面に構成できます。 Web サーバーは、WebSphere Portal がグローバル SSO ドメインに参加する場合、静的リソース (画像やスタイルシートなど) を供給する機能、および企業のシングル・サインオン (SSO) エージェント用のプラグイン・ポイントを提供します。

以下の図には、単一サーバー環境での一般的なトポロジーが示されています。 必要なサーバーは 1 つのみです。 WebSphere PortalWebSphere Application Server、およびデータベースはすべての同一のサーバー上にインストールされます。

単一サーバー・インストールの図。WebSphere Portal、WebSphere Application Server、およびデフォルト Derby データベースが 1 つのサーバー上にあります。

スタンドアロン・サーバー・トポロジー

スタンドアロンのシナリオでは、データベース・サーバー、LDAP サーバー、および Web サーバー・ソフトウェアが IBM WebSphere Portal とは別の物理サーバーにインストールされるので、 シングル・サーバーとは異なります。 この構成を使用すると、ネットワーク内でソフトウェアを分散できるので、処理の負荷を分散できます。

スタンドアロン構成の場合、ネットワーク内で既存のサポートされるデータベースを使用でき、既存のサポートされる LDAP ディレクトリーを使用できます。 LDAP サーバーで認証を行うように IBM WebSphere Portal を構成できます。 以下の図には、スタンドアロン・サーバーでの一般的なトポロジーが示されています。 HTTP サーバー (Web サーバーとも呼ばれる) は保護されているネットワーク内でサーバーにインストールされます。 LDAP サーバーとデータベース・サーバーも別々のサーバーにインストールされます。 WebSphere PortalWebSphere Application Server は同じサーバーにインストールされます。

スタンドアロン・サーバー構成の図。
WebSphere Portal、Web サーバー、およびデータベースは別々のサーバーにインストールされます。

クラスター化サーバー・トポロジー

容量および可用性を増大させるために、IBM WebSphere Application Server Network Deployment を使用して、複数のポータル・サーバーをクラスター化できます。IBM WebSphere Application Server Network Deployment では、ポータルは共通の構成を共有し、また負荷がすべてのクラスター・インスタンスに均等に配分されます。

IBM WebSphere Portal は、一連のサーバーを中央で管理しクラスター化するためのデプロイメント・マネージャー・サーバー・タイプを提供する、IBM WebSphere Application Server 配布の WebSphere Application Server Network Deployment に標準装備されています。 一連のポータル・サーバーをクラスター化するとは、すべてのポータル・インスタンスが、同じ構成 (データベース、アプリケーション、ポートレットを含む) およびサイト設計を共有するということを意味します。 クラスターが提供するドメインで、大半の管理アクションが 1 回実行され、クラスター内の各サーバーと同期されます。 これにより、管理が単純化されると共に、すべてのクラスター・メンバーの構成および振る舞いが確実に等しくなります。

サーバー・クラスターはまた、セッションおよびキャッシュ・データを複製し、クラスターのすべてのメンバー間で整合性を保たせることのできる共有ドメインを提供します。 またクラスターは、アプリケーション同期機構も提供します。これは、クラスター全体でのアプリケーション管理 (開始、停止、更新など) の整合性を確保します。

WebSphere Application Server は、HTTP サーバー・プラグインを提供します。これにより、クラスターのすべてのメンバー間のユーザー・トラフィックのバランスを取ることができますし、また「セッション・アフィニティー」という機能により、セッション中、特定のクラスター・インスタンスにユーザーをバウンドしたままにすることで効率とパフォーマンスを改善できます。 さらに、クラスター・メンバーがダウンした場合、プラグインのワークロード管理機能は、インスタンスが使用できなくなったことを認識し、代わりのトラフィックの経路を指定します。

IBM WebSphere Virtual Enterprise をインストールして、パフォーマンスとロード情報をモニターし、ワークロードに基づいてクラスター・メンバーを動的に作成したり除去したりできます。 WebSphere Virtual Enterprise は、On Demand Router と呼ばれる高度かつインテリジェントなルーティング機能です。これには、ルーティングおよびサービス・ポリシーを定義する機能が加えられた、HTTP Server プラグインのすべての機能が含まれます。 On Demand Router は、動的クラスター環境をセットアップする場合に必要です。

クラスターには、垂直クラスターと水平クラスターの 2 つのタイプがあります。 ほとんどの大規模デプロイメントでは、両方のクラスター・タイプを混合して使用します。

また、複数のポータル・クラスターをデプロイして、可用性、フェイルオーバー、および災害復旧を向上させることもできます。

WebSphere Portal をインストールしてクラスターを作成する前に、クラスターの正常なデプロイメント計画に役立つ、クラスターに関する考慮事項のすべてのトピックを検討してください。

垂直クラスター・トポロジー

垂直クラスターには、ノード内に複数のクラスター・インスタンスがあります。 一般に、ノードは 1 つの管理対象セル内の単一の物理サーバーを表しますが、1 つの物理サーバーに対して複数のノードがあることもあります。 デプロイメント・マネージャーの管理コンソールを使用して、ノードに垂直クラスターをさらに追加するのは非常に簡単です。なぜなら、それぞれの追加の垂直クラスター・インスタンスは、最初のインスタンスの構成を複製するからです。追加のインストールまたは構成は必要ありません。

単一ノードで作成できる垂直インスタンスの数は、ローカル・システム内の物理リソース (CPU およびメモリー) の可用性によって異なります。 垂直クラスター・インスタンスが多すぎると、サーバーの物理リソースを使い果たす可能性があります。その場合、必要であれば、水平クラスター・インスタンスを作成して容量を増やすことができます。

以下の図は、垂直クラスターを図示しています。 単一ノードに IBM WebSphere Portal の複数インスタンスがインストールされています。 このノードは、デプロイメント・マネージャーによって管理されています。 ノード上の各インスタンスは、同じ LDAP サーバーで認証を行い、同じデータベース・サーバーにデータを保管します。 図には示されていませんが、フェイルオーバー、パフォーマンスの向上、および高可用性が必要な場合は、データベースと LDAP サーバーをクラスター化することもできます。

垂直クラスターの図。この図について詳しくは、このトピックのテキストを参照してください。
水平クラスターと垂直クラスターの組み合わせ

ほとんどの大規模ポータル・サイトでは、追加マシンを取り込む前に、単一マシンのリソースを最大限に活用するため、水平および垂直のクラスタリングの組み合わせを取り込んでいます。

この図は、2 つの水平クラスター・メンバーのノード A および B を示します。ノード A と B の両方は 3 つの垂直クラスター・メンバーを含みます。
この図は、2 つの水平クラスター・メンバーのノード A および B を示します。ノード A と B の両方は 3 つの垂直クラスター・メンバーを含みます。

複数のクラスター

サーバーの可用性、フェイルオーバー、および災害復旧を向上させると同時に、地理的に広範囲に及ぶデプロイメントを支援するために、同じポータル・サイト用に複数のポータル・クラスターをデプロイすることを考慮するのが最善です。 複数のクラスターを使用すれば、他のクラスターを実動で使用したまま、1 つのクラスターを実動使用から外して、アップグレードやテストを実施できます。 これは、保守のための期間を必要としない、100% の可用性を達成するための最善の方法です。 また、クラスターをそのサービスの提供対象者に対してより近くにデプロイして、クラスターが提供するコンテンツの応答を改善できます。

複数のポータル・クラスターをデプロイする際には、ほとんどの部分において、各クラスターは完全に独立したシステムとして見なされる必要があります。 各クラスターは、独立して管理され、独自の構成を持ち、他のクラスターからは分離しています。 これはポータル・トポロジーの保守能力を向上させると同時に、その高可用性を保護します。この規則の唯一の例外は、ポータル・データベース・ドメインのいくつか、特に Community および Customization ドメインを共有することです。これらは、同じポータル・サイトを示す複数のクラスター間で共有されるように設計されています。 これらのドメインは、エンド・ユーザー自身が所有するポータル構成データを保管するので、同一ポータル・クラスターすべての間でこのデータの同期を保つことは重要です。 詳しくは、データベース考慮事項を参照してください。

各クラスターは同じデータ・センター内でデプロイできます。これは、保守容易性の向上に役立ち、また障害分離を向上させます。または、複数のデータ・センターにわたってデプロイすることもできます。これは、自然災害およびデータ・センター障害から保護したり、単により広範囲なポータル・サイトを提供したりすることができます。 クラスター間が遠くに離れれば離れるほど、クラスター間のネットワーク待ち時間に与える影響が大きくなります。そのため、共有ドメインのクラスター間で同じ物理データベースを共有することや、データベースの同期を保つためにデータベース複製技法に頼ることは避けた方が良い場合があります。

一般に、複数のポータル・クラスター・トポロジーでは、HTTP サーバー・プラグインの構成はセル固有なので、HTTP サーバーはクラスターごとに専用化されます。データ・センター (HTTP サーバーの貯蔵所) 間のトラフィックを経路指定するために、別個のネットワーク・ロード・バランシング装置が使用され、場所またはランダムなサイト選択 (DNS 解決などによる) のいずれかに基づいて、ユーザーを特定のデータ・センターに経路指定するための規則が設定されます。 同じユーザーが同じデータ・センターに経路指定されることを予想してその設定が保持されるので、データ・センターの選択に基づいたドメインまたは場所が優先されます。このことは、セッション・アフィニティーおよび最適な効率を保持するのに役立ちます。 経路指定の選択に基づいた DNS 解決では、ライブ・セッション中にユーザーを突然、別のデータ・センターに経路指定すると、ランダムな振る舞いを引き起こす可能性があることに注意してください。 このことが生じた場合、ユーザーが認証され、新規サイトで最後の時点からの再開を試行すると、ポータル・サイトでユーザーが実行したことは壊される可能性があります。セッションの複製および (または) ポートレット・レンダリング・パラメーターの適正な使用は、この影響を小さくするのに役立ちます。

複数のポータル・クラスターを使用する以下の構成のうちの 1 つを採用できます。
アクティブ / アクティブ
この構成では、すべてのポータル・クラスターがエンド・ユーザーのトラフィックを同時に受信します。 ネットワーク・ロード・バランサーおよび HTTP サーバーにより、各クラスター内の各サーバーにトラフィックを均等に分散させることができます。 1 つのクラスターで保守が必要な場合、すべての実動トラフィックを他のクラスターに切り替えます。 これはつまり、1 つのクラスターの保守中に、残りのアクティブ・クラスターがすべての実動トラフィックを処理できるように、トポロジーをサイズ変更する必要がある、また保守はオフピーク時に実行する必要がある、ということです。
アクティブ / パッシブ
この構成では、通常の環境において、すべての実動トラフィックが、使用可能なポータル・クラスターのサブセット (例えば、2 つのうち 1 つ、3 つのうち 2 つなど) に経路指定されます。 トラフィックを全く受信していないクラスターが常時 1 つあります。 保守は一般に、まず最初にオフライン・クラスターに適用され、その後、実動トラフィックに適用されます。残りのクラスターが 1 つ 1 つ取り出されて、同じ仕方で保守を受けます。 このため、クラスターのサブセットは、実動トラフィックすべてを処理できるだけのサイズでなければなりません。

この図は、異なるセル内の複数のクラスターを表しています。各セルには独自のデプロイメント・マネージャーが含まれています。

各クラスターが異なるセルにある複数のポータル・クラスターをデプロイする代わりに、複数のポータル・クラスターを同じセル内にデプロイすることもできます。 異なるセルでは、クラスター間を完全に分離し、他のクラスターに影響を与えることなく各クラスターの全局面を自由に保守することができます。 ただし、異なるセルは異なるデプロイメント・マネージャーを必要とするため、各クラスターを管理する異なる管理コンソールが必要になります。 同じセル内の複数のクラスターは、単一コンソールでの管理を可能にし労力を削減しますが、複数のクラスター間でリソースを高度に共有するため、クラスターを保守するための労力のレベルが高くなります。

単一セル内の複数のポータル・クラスターがそれぞれ使用される間、特に単一層のコンテンツのオーサリングおよびレンダリング・サーバーを 1 つにまとめる際に、管理の複雑さが大幅に増します。 複数のポータル・クラスターを複数のセルにデプロイして、管理をできるだけ単純に保つことをお勧めします。 詳しくは、『単一セル内の複数のポータル・クラスター』を参照してください。

この図は、単一セル内の複数のクラスターを表しています。各セルは同じデプロイメント・マネージャーによって管理されます。

ポータル・ファーム・トポロジー

ポータル・ファーム・トポロジーには、同一に構成される、一連のスタンドアロン・サーバー・インスタンスが含まれます。 サーバー・ファームは、拡張性に富んだ、可用性の高いサーバー環境を構築および保守するための最も簡単な方法です。

制約事項: z/OS にインストールされた場合には、このフィーチャーは Express エディションまたは Enable エディションには適用されません。

この図は、同一に構成された一連のスタンドアロン・サーバー・インスタンスを表します。これには、フロントエンドにブラウザー・クライアントおよびネットワーク・ロード・バランス、バックエンドに一般的なデータベース・ドメインが含まれます。

クラスター・デプロイメントまたはポータル・ファーム・デプロイメントを選択する場合

クラスター・デプロイメントを選択することにも利点があり、ポータル・ファーム環境を選択することにも利点があります。 これらの利点には、パフォーマンスと管理の面での利点が含まれます。 この情報では、クラスター・デプロイメントとポータル・ファーム・デプロイメントのシナリオを、どのようなときに選択するのかを説明します。

クラスター・デプロイメントを選択する場合
以下の項目のいずれかがビジネス要件に一致する場合、クラスター・デプロイメントを選択すると良いでしょう。
  • 各サーバー上で個別にリソースを管理する責任を持つよりも、包括的な中央管理ポイント (デプロイメント・マネージャーで提供される) があるほうが良い。
  • クラスター内の各サーバーにおいてではなく、1 つのセル内で実行される 1 つのインスタンスだけを必要とするサービス (EJB、または JCA コネクターとして実装されたその他のサービスなど) がある。
  • ファームの各サーバーではなく、クラスターの 1 つのサーバーでのみ実行する必要のあるタスクをスケジュールに入れている。
ポータル・ファーム・デプロイメントを選択する場合
以下の項目のいずれかがビジネス要件に一致する場合、ポータル・ファーム・デプロイメントを選択すると良いでしょう。
  • クラウド・コンピューティング環境などのように、マシンを追加したり除去したりすることにより、容量をより動的に拡張したり縮小したりすることが必要である。
  • 大規模なデプロイメント環境 (例えば、100 以上のサーバー・インスタンス) があり、ポータル・ファーム・デプロイメントでなければ管理対象セルの境界が大きくなりすぎる。
  • ポータル・ファーム・デプロイメントでなければデプロイメント・マネージャーによってクラスター内で実行されるような管理アクション (サーバーまたはアプリケーションの再開など) を、一連の同一サーバーに対して自動化して実行するほうが望ましい。
  • メンテナンスおよびアプリケーションの更新中に連続可用性を維持するために、複数のクラスターは必要としない。
ポータル・ファームの考慮事項

「ファーム」という用語は、同一の構成を持つ一連のスタンドアロン・サーバー・インスタンスを指す言葉です それらがスタンドアロンであるという事実は、複雑なクラスター構成あるいは内部サーバーの認識状態について心配することなく、ファームのサイズを増減させることができるということを示しています。 サーバー・ファームは、拡張性に富んだ、可用性の高いサーバー環境を構築および保守するための最も簡単な方法です。

ポータル・ファームが単純であることに関連したコストがあります。これは、アプリケーション・サーバーのクラスター化の恩恵を受けられないことに由来します。 これらの制約、およびこれらの制約がビジネス上のリスクを引き起こすかどうかを理解することは、ポータル・ファームが適したデプロイメント・パターンであるかどうかを判断するのに肝要です。
共通オペレーティング・システム (共用インストールのみ)
共用ファイル・システムを使用する場合、ファーム内の元の IBM WebSphere Portal インストール済み環境を含む、各ファーム・インスタンスは、同じオペレーティング・システム (Linux のバリエーションも含む) 上になければなりません。
セッション・パーシスタンスおよび複製
セッション・パーシスタンスおよび複製は、場合によっては分散セッション・データベースを使用することによってのみ可能です。 セッション・パーシスタンスおよび複製が必要な場合、すべての WebSphere Portal ファーム・インスタンスでは、同じデータベースおよびセッション・テーブルを指定する必要があります。 WebSphere Portal はデフォルトで、有効なセッション・パーシスタンスを必要としません。
動的キャッシュの複製
スタンドアロン・インスタンスのファームをまたぐ動的キャッシュの複製は、サポートされません。そのため、各ファーム・インスタンスのキャッシュを個々に保守する必要があります。 これは、ポータル構成および公開されたコンテンツに対する更新が道理にかなった時間内に反映されるように、キャッシュの有効期限を構成する必要があることを意味します。 「道理にかなった」時間は、ビジネス要件によって異なります。 キャッシュについての追加情報は、下記の『ポータル・ファームのキャッシュ管理に関する考慮事項』リンクを参照してください。
アプリケーション・サーバー構成の更新の同期を管理するセルはない (固有ファーム・インストールのみ)
アプリケーション・サーバー構成の更新の同期を管理するセルはありません。つまり、アプリケーション・サーバー構成に対する更新 (エンタープライズ・アプリケーションに対する更新やデータ・ソース構成に対する変更など) は、ファーム内の各サーバー上で繰り返す必要があります。
各ポータル・インスタンスには、独自のリリース・データベースが必要 (固有ファーム・インストールのみ)
各ポータル・インスタンスには、独自のリリース・データベースが必要です。つまり、ポータル構成の更新は、ファーム上のすべてのポータル・インスタンスに対して行う必要があります。
ポータル検索
ポータル検索は、それがクラスター環境の一部であるかのように構成する必要があります。 検索サーバーは、ファーム外部の別個のポータル・インスタンスとしてセットアップする必要があります。これは、ファームを検索するよう構成されます。 詳しくは、下記の『リモート検索サービスの使用』リンクを参照してください。
共用リソース (共用インストールのみ)
Java クラスや JDBC などのすべてのシステム・リソースは、ポータル・インスタンスの開始時に検出できるよう、ファーム内の各サーバーが使用する共用ファイル・システム内に置くようにします。
セキュリティー

すべてのファーム・インスタンスには、同一のユーザー・リポジトリー構成 (LDAP サーバーなど) など) を含む同一のセキュリティー構成がなければなりません。そうすることで、各ファーム・インスタンスが同じユーザー情報およびグループ情報にアクセスできるようになり、単一の同じシングル・サインオン方式でシームレスに参加できます。

ポータル・ファームのキャッシュ管理に関する考慮事項

サーバー・インスタンスは独立しているため、動的キャッシュ・コンテンツの調整またはそのコンテンツの無効化はありません。 そのため、1 台のサーバーで行われた変更が、ファーム内の別のサーバー上には即座に反映されないことがあります。 このため、キャッシングの利点が失われない程度に道理にかなった時間内でキャッシュの有効期限が切れるように構成して、更新が適時に反映されるようにすることは重要です。

WebSphere Portal 内には、主に以下の 2 つのキャッシング領域があります。
ポータル・キャッシュ
ポータル・キャッシュは、ナビゲーション、ページ・レイアウト、アクセス制御などのポータル構成をカバーします。 これらは、有効期限が切れるよう自動的に構成されます。ただし、その時間はキャッシュごとに異なります。 一般的に、管理上の変更がサーバー上で直接行われるときや、ユーザーが WebSphere Portal をログオフして再度ログインするときには、ほとんどの更新は即座に反映されます。

固有のインストール済み環境が 1 つになったファームでは、管理アクションはすべてのサーバーに対して必要であり、すべてのサーバーに手動で適用する必要があるので、 ポータル・キャッシュの有効期限は一般的には問題とはならないはずです。

共用構成の場合、一般的に構成変更は、そのキャッシュの有効期限が切れるか、または個々のサーバーが再始動したときに、ファーム全体に反映されます。 追加情報については、関連概念にある『キャッシュ』のトピックを参照してください。

コンテンツ・キャッシュ
コンテンツ・キャッシュには特別な注意が必要です。 コンテンツ・キャッシュが更新されるのは、オーサリング・アクティビティーまたはシンジケーションのいずれかによって、コンテンツ項目が変更された場合です。 ファームのシナリオでは、1 台のサーバーがコンテンツ・シンジケーションのサブスクライバーとして指定されます。 シンジケーションでは、このサーバー上で通常どおりにキャッシュが更新されます。 コンテンツ・キャッシュの無効化メッセージ Bean をファーム内のサーバー上にデプロイし、サブスクライバー・サーバーからのメッセージをコンシュームするようにしなければなりません。 サブスクライバーからのコンテンツ項目更新メッセージをコンシュームすることにより、すべてのサーバー上のコンテンツ・キャッシュの同期を保って最新の状態にすることができます。
ポータル・ファームのセットアップ・オプション

インストールおよびセットアップのプロセスを始める前に、ポータル・ファームの各種構成オプションについて調べます。

ファームにおいて各インスタンスをセットアップするため、以下のアプローチの 1 つを選択します。
  • WebSphere Portal は、ファームに提供される各サーバー上に、単純にインストールできます。 このプロセスは、以下のアプローチのいずれかを使用して、迅速に実行できます。
    • VMWare などの仮想化のテクノロジーを使用して、WebSphere Portal と共にインストールされて構成された同一のオペレーティング・システムを一括複製できます。
    • ポータル・クローン作成。これは、十分に構成された WebSphere Portal インストールを一括複製する機能です。これを使用すれば、 仮想化テクノロジーを必要とせずに、一連の同一サーバーを迅速にセットアップできます。 developerWorks の WebSphere PortalZone に移動して、「cloning」で検索し、このガイドの最新バージョンを見つけてください。
  • 単一インストールおよびプロファイルを、複数のシステム間で共用できます。 いくつかの特定の構成が変更され、サーバー固有の可変ファイルが確実に共用ファイル・システムの外部に置かれるようになったため、元のサーバーのインストール済み環境および構成ファイル・システムを共用して新しいサーバー・インスタンスを開始するだけで、元のサーバー上で行う場合のように、新しいポータル・インスタンス (プロセス) を非常に迅速に作成することができます。 サーバー構成が共用されるため、すべてのファーム・インスタンスが同一の構成を持ち、いくつかの同一のデータベース・ドメインを再使用します。
ポータル・ファームのデータベースの共用およびロード・バランシング

ポータル・ファーム構成におけるデータベースの共用およびロード・バランシングについては、固有の考慮事項があります。

データベースの共用

ファームの構築に独立サーバー・インストール・アプローチが使用される場合、 リリース・ドメイン以外のすべてのデータベース・ドメインを共用できます。 すべてのファーム・インスタンスには独自のリリース・データベースを必要とします。さらに具体的に言うと、すべてのアプリケーション・サーバー・プロファイルには独自のリリース・データベースを必要とします。 共用ファイル・システム・ポータル・ファームの場合、すべてのデータベース・ドメインを共用できます。なぜなら、リリース・データがバインドされるアプリケーション・サーバー構成も共用されるからです。

ロード・バランシング

効率的なキャッシングとパフォーマンスの両方のため、また適正なログイン機能を確保するために、クライアントと特定のファーム・サーバー・インスタンスとの間のアフィニティーを維持することは重要です。 ログイン・プロセス中に、同じサーバーに対していくつかの要求ステップが必要になります。 ログイン・プロセス中にサーバー間を移動すると、ログインに失敗することがあります。

アフィニティーを確保しながらサーバー間のロード・バランシングを行う機能をサポートする、市販の多数のネットワーク・アプライアンスがあります。 WebSphere Portal は IBM HTTP Server が付属していますが、そのアプリケーション・プラグインも、サーバー間のロード・バランシングをサポートしています。 アプリケーション・サーバー・プラグインによるロード・バランシングでは、アプリケーション・サーバー・クラスターを使用していることが前提になっているため、この技法を使用するには余分の構成が必要です。 ポータル・ファームに機能を提供するよう HTTP Server をセットアップする方法については、『ポータル・ファームのセットアップ』を参照してください。

Web Content Management の単一サーバー・トポロジー

小規模な Web サイトまたはイントラネット・サイトのみを必要とする組織では、Web Content Management の単一サーバー・トポロジーを実装できるでしょう。 単一サーバー構成では、オーサリングと配信は同じサーバー上で行われます。 大規模な Web サイトまたはイントラネット・サイトを必要とする組織の場合、この構成は推奨されていません。

以下のトポロジー図は、Web Content Management の単一サーバー構成を示しています。 Web サーバーは、ブラウザー・クライアントからの着信要求を転送します。 Web Content Management、WebSphere Portal、および WebSphere Application Server は、同一のサーバーにインストールされています。 許可ユーザー情報を保管する LDAP サーバーは、専用のサーバーにインストールされています。 コンテンツを保管するデータベースも、専用のサーバーにインストールされています。 この図ではクラスター構成は示されていませんが、Web Content Management サーバーをクラスター化することもできます。 同様に、LDAP サーバーおよびデータベース・サーバーをフェイルオーバー用にクラスター化することもできます。

Web Content Management の単一サーバー構成の図。この図について詳しくは、このトピックのテキストを参照してください。

以下のアクションが単一サーバーで実行されます。
  • ドラフトの作成
  • ドラフトの承認
  • 変更内容の検査
  • 変更内容の公開
  • コンテンツのホスト
ハードウェアおよびリソースに関する考慮事項
  • 同じ環境内でコンテンツをオーサリングおよび配信するとリソースが集約されるので、 デプロイする環境のタイプはオーサリングと配信の同時発生を許容できる堅固なものでなければなりません。 クラスター化サーバーの使用は、単一サーバー構成における一般的なソリューションとなります。
  • コンテンツは、Web コンテンツ・ビューアー・ポートレット、Web コンテンツ・サーブレット、または事前レンダリングされたサイトのいずれかを使用して配信できます。

Web Content Management のデュアル・サーバー構成

トラフィック量が多い大規模な Web サイトを必要とする組織、またはコンテンツをオーサリングするユーザーが多数存在する組織では、デュアル・サーバー構成を実装する必要があります。デュアル・サーバー構成では、オーサリングは 1 つのサーバーまたはサーバー・クラスターで行われ、コンテンツは別のサーバーまたはサーバー・クラスターに配信されます。 作成者はオーサリング・サーバーにアクセスして作業する一方、Web サイト・ユーザーは配信サーバーにアクセスします。これにより、各サーバーの負荷が軽減され、オーサリング環境をファイアウォールの背後に配置できるようになります。

以下の図は、Web Content Management のデュアル・サーバー環境を示しています。 配信サーバーとオーサリング・サーバーは両方とも、同一の LDAP サーバーおよびデータベース・サーバーにアクセスして、共通のユーザー、ユーザー・グループ、およびコンテンツにアクセスします。 同じ LDAP 構成を使用することは、Web Content Management において重要です。 Web サイトのユーザーは Web サーバー経由でサイトにアクセスし、その Web サーバーによってユーザーは配信サーバーに向けられます。配信サーバーでは、Web コンテンツ・ビューアー (図に示されている)、Web コンテンツ・サーブレット、または事前レンダリングされたサイトのいずれかを使用できます。 新規コンテンツは、配信サーバーにシンジケートまたは公開されます。

Web Content Management のデュアル・サーバー構成。この図について詳しくは、このトピックのテキストを参照してください。

オーサリング・サーバーでは、以下のアクションが実行されます。
  • ドラフトの作成
  • ドラフトの承認
  • 変更内容の検査
  • 変更内容の公開
  • 配信サーバーへの変更内容のシンジケート
配信サーバーでは、以下のアクションが実行されます。
  • コンテンツのホスト
  • コンテンツの変更内容のサブスクライブ
ハードウェアおよびリソースに関する考慮事項
  • オーサリング環境は、多数の Web サイト・クリエーターおよび Web コンテンツ作成者に対応するために、通常はクラスター環境となります。
  • 配信環境として、以下のものがあります。
    • オーサリング環境にサブスクライブする Web コンテンツ配信サーバーまたはクラスター。 コンテンツは、Web コンテンツ・ビューアー・ポートレット、Web コンテンツ・サーブレット、または事前レンダリングされたサイトのいずれかを使用して配信できます。
    • オーサリング環境にサブスクライブし、Web コンテンツ・ビューアーを使用して Web コンテンツを配信する、ローカルの WebSphere Portal 実稼働環境。
    • WSRP および JSR 286 Web コンテンツ・ビューアーを使用してオーサリング環境からのコンテンツを表示する、リモートの WebSphere Portal 実稼働環境。
  • この図にはファイアウォールが示されていませんが、必要に応じてオーサリング・サーバーと配信サーバーの間に配置することもできます。
シンジケーション・オプション
以下に示す 2 つのシンジケーション・オプションを検討できます。
自動片方向シンジケーション
このオプションでは、オーサリング環境での変更内容が、配信環境に自動的にシンジケートされます。 コンテンツの変更内容が表示サイト上で常に更新されるようにする場合は、このオプションを実装できるでしょう。
手動片方向シンジケーション
このオプションでは、オーサリング環境での変更内容が、単一のバッチで配信環境にシンジケートされます。 設定された日にのみ表示サイトを更新する場合は、このオプションを実装できるでしょう。 オーサリング・サーバーで加える変更内容は、それらの変更内容を公開できる状況になるまで徐々に累積されます。

Web Content Management のステージング・サーバー・トポロジー

多数のサイト・ユーザーおよびコンテンツ作成者を伴う大規模で複雑な Web サイトを配信する必要がある場合は、ステージング・サーバー構成を実装します。ステージング・サーバーを実装すると、精度、設計上の問題、およびパフォーマンスを検査する環境を実現できます。 ステージング・サーバー構成では、オーサリング、ステージング、および配信は異なるサーバーで別個に扱われます。 ステージング環境は、ユーザー受け入れテスト (UAT) のために、 または単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できるようにするために使用できます。

以下の図は、ステージング・サーバー・トポロジーを示しています。 配信、ステージング、およびオーサリングの環境ごとに、異なるサーバーまたはサーバーのクラスターがあります。 配信、ステージング、およびオーサリングの環境ではすべて、同一の LDAP サーバーおよびデータベース・サーバーにアクセスします。 必要に応じて、LDAP サーバーおよびデータベース・サーバーもクラスター化することができます。 Web サイトのユーザーは、Web サーバー経由で配信サーバーにアクセスします。作成者はオーサリング・サーバーにアクセスし、コンテンツは品質保証検査のためにステージング・サーバーにシンジケートされてから、配信サーバーに公開されます。

Web Content Management のステージング・サーバー・トポロジー。この図について詳しくは、このトピックのテキストを参照してください。

オーサリング・サーバーでは、以下のアクティビティーが実行されます。
  • ドラフトの作成
  • ドラフトの承認
  • 変更内容の検査
  • 新規または変更済みコンテンツの公開
  • ステージング・サーバーへのコンテンツのシンジケート
ステージング・サーバーでは、以下のアクティビティーが実行されます。
  • ユーザー検証テスト
  • パフォーマンス・テスト
  • 配信サーバーへのコンテンツのシンジケート
配信サーバーでは、以下のアクティビティーが実行されます。
  • Web サイト・ユーザー用のコンテンツのホスト
ハードウェアおよびリソースに関する考慮事項
  • オーサリング環境は、多数の Web サイト・クリエーターおよび Web コンテンツ作成者に対応するために、通常はクラスター環境となります。
  • ステージング環境は、以下のものから構成できます。
    • オーサリング環境にサブスクライブする Web コンテンツ配信サーバーまたはクラスター。これは、単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できるようにするために使用されます。
    • 配信環境の完全なレプリカ。 このタイプの環境は、システム UAT によって、配信される Web サイトが正確でエラーがなく負荷の下でも実行可能なものであることを確認するために使用されます。
  • 配信環境は、以下のものから構成できます。
    • ステージング環境にサブスクライブする Web コンテンツ配信サーバーまたはクラスター。コンテンツは、Web コンテンツ・ビューアー・ポートレット、Web コンテンツ・サーブレット、または事前レンダリングされたサイトのいずれかを使用して配信できます。
    • ステージング環境にサブスクライブし、Web コンテンツ・ビューアーを使用して Web コンテンツを配信する、ローカルの WebSphere Portal 実稼働環境。
    • リモートの WebSphere Portal 実稼働環境。 このシナリオでは、Web コンテンツ配信サーバーがステージング環境からサブスクライブし、リモートの WebSphere Portal 実稼働環境が WSRP および JSR 286 Web コンテンツ・ビューアーを使用して Web コンテンツ配信サーバーからのコンテンツを表示します。
シンジケーション・オプション
  • オーサリング環境からステージング環境への自動的な片方向シンジケーション。
  • ステージング環境から配信環境への手動による片方向シンジケーション。

Web Content Management トポロジー

Web Content Management システムを使用するには、一連の Web Content Management 環境を WebSphere Portal システム全体にデプロイする必要があります。 Web Content Management 環境を検討することは、各環境で何が行われるか、および物理サーバーをどのようにセットアップするかを理解するために役立ちます。 Web Content Management は、WebSphere Portal インストール・ユーザー・インターフェースを使用してインストールされます。

Web コンテンツ・システム内のサーバーまたはクラスターは、それぞれに個別のデータ・リポジトリーを必要としますが、通常は同じ LDAP を共用します。Web Content Management システムは、分離してデプロイすることも、WebSphere Portal システムと並列させてデプロイすることもできます。

Web コンテンツ・システムの概要

デプロイする Web コンテンツ・システムのタイプは、 Web コンテンツ・システムのサイズ、配信される Web サイトのタイプ、および Web コンテンツを作成および表示するユーザーの数によって決まります。

Web コンテンツ・システムのタイプ
Web コンテンツ・システムには、以下の 3 つの主なタイプがあります。
単一環境システム
ここでは、オーサリングおよび配信が単一環境内で生じます。 このタイプの環境は、イントラネットなどの小さな Web サイトを配信する小さな組織によってデプロイされます。同じ環境内でコンテンツをオーサリングおよび配信するとリソースが集約されるので、 デプロイする環境のタイプはオーサリングと配信の同時発生を許容できる堅固なものでなければなりません。 例えば、クラスター化サーバーの使用は、単一インスタンス・システムの一般的なソリューションとなります。

単一環境システムは、Web コンテンツのオーサリングおよび配信の両方で使用される単一サーバーまたはクラスターで構成されます。

二重環境システム
ここでは、オーサリングおよび配信が異なる環境に分割されます。 このモデルにより、オーサリングおよびデリバリーの両方の負荷が軽減され、 またオーサリング環境をファイアウォールの背後に配置できるようになります。 このタイプのシステムは、外部に向けた Web サイトを配信するとき、 または多数のユーザーがコンテンツをオーサリングするか多数のユーザーが Web サイトを表示する場合に使用されます。

二重環境システムは、オーサリング環境および配信環境で構成されます。

ステージ・システム
ここでは、ステージング環境がオーサリング環境と配信環境との間に追加されます。 ステージング環境は、ユーザー受け入れテスト (UAT) のために、 または単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できるようにするために使用できます。このシステムは、多数のコンテンツ作成者が存在する大きく複雑なサイトを配信するために、 配信される Web サイトが正確でエラーがなく負荷の下でも実行可能なものであることを確認する必要がある場合にデプロイされます。

ステージング・システムは、オーサリング環境、ステージング環境 (ユーザー受け入れテストが実行される場合があります)、および配信環境で構成されます。

環境のタイプ
オーサリング環境
オーサリング環境は Web コンテンツの作成と管理に使用されます。 これはコンテンツ作成者および Web サイト設計者によって使用される環境です。オーサリング・システムは、以下のものから構成できます。
  • オーサリング・サーバーまたはクラスター。
  • 配信環境にシンジケートする前にサイトおよびコンテンツの更新をテストできる、個別の UAT サーバー。
ステージング環境
ステージング環境は、以下のものから構成できます。
  • 単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できる、個別の保存用サーバー。保存用サーバーを対にして使用すると、環境に冗長性を組み込むことができます。
  • サイトおよびコンテンツの更新を確認するため、および配信環境のパフォーマンスをテストするために UAT を実行できる、配信環境の完全なレプリカ。
配信環境
この環境は、Web サイト・ビューアーによって使用されます。配信環境は、以下のものから構成できます。
  • Web コンテンツ・サイトが HTML ファイルのセットとして事前レンダリングされていて、 その後に静的 Web サイトを配信するために使用される、事前レンダリングされたサイト。
  • コンテンツがサーブレットを使用して配信される、WebSphere Portal サーバーまたはクラスター。サーブレット配信は、動的コンテンツを含み WebSphere Portal コンテンツまたはアプリケーションを含まない Web サイトの配信に使用されます。
  • コンテンツがローカルまたはリモートの Web コンテンツ・ビューアー・ポートレットを使用して配信される、WebSphere Portal サーバーまたはクラスター。Web コンテンツ・ビューアー・ポートレットは、動的 Web コンテンツを他のポートレットまたはアプリケーションと共に含む Web サイトの配信に使用されます。
  • 上記のすべての組み合わせ。

Web コンテンツのオーサリング環境

オーサリング環境は Web コンテンツの作成と管理に使用され、コンテンツ作成者および Web サイト設計者によって使用されます。

サーバー・タイプ
ほとんどの Web Content Management サイトでは、数多くのコンテンツ作成者をサポートする必要があります。 クラスター化サーバーのソリューションが、このシナリオにおける最良のソリューションです。
標準的なオーサリング環境

標準的なオーサリング環境は、ステージング環境または配信環境と直接シンジケートする単一のオーサリング・クラスターで構成されます。 例:

標準的なオーサリング環境。この例では、標準的なオーサリング環境は、ステージング環境または配信環境と直接シンジケートする単一のオーサリング・クラスターで構成されます。オーサリング環境は、ドラフトの作成、ドラフトの承認、変更のテスト、変更の公開、および配信環境へのシンジケートを行うために使用できます。

テストを行うオーサリング環境

テスト環境をオーサリング環境に追加すると、コンテンツ管理システムおよび Web サイトでユーザー受け入れテストを実行できるようになります。 例:

テストを行うオーサリング環境。この例では、ドラフトの作成、変更の承認、変更のテスト、およびオーサリング環境からステージングへのシンジケートを行うことができます。
サイト UAT 環境では、変更の公開、システムによる変更のテスト、およびオーサリング環境へのシンジケートが可能です。
オーサリング環境から、配信環境にシンジケートできます。

非集中オーサリング環境
コンテンツ作成者が別の場所に存在する場合、またはコンテンツ作成者のさまざまなグループが存在する場合には、 一連の非集中オーサリング・クラスターをデプロイすることを検討できます。 このシナリオは、非集中コンテンツ作成者がさまざまなコンテンツ・ライブラリーに保管された別個のコンテンツを処理する場合に最適です。

例えば、ユーザーが複数の場所に分散している場合は、それぞれの場所に 1 つのローカル・オーサリング環境をインストールする方が効率的でしょう。集中オーサリング環境のあるすべてのオーサリング環境の間で、両方向シンジケーションが使用されます。これにより、すべてのリモート・ロケーションで加えられた変更内容を、すべてのユーザーに表示できるようになります。

非集中オーサリング・ダイアグラム。この図について詳しくは、このトピックのテキストを参照してください。

非集中オーサリングでは、オーサリング環境の間で更新内容が矛盾するというリスクが生じます。 矛盾のリスクを減らすには、各オーサリング環境に、異なるサイトまたは異なるサイトのセクションを割り振ることができます。 また、ユーザーの役割ごとに別々のオーサリング環境を使用することもできます。例えば、コンテンツ作成者は、プレゼンテーション・テンプレート設計者とは異なるオーサリング環境を使用できます。

各非集中オーサリング環境へのアクセスは、オーサリング・ポートレット・アクセス制御と項目のセキュリティーの設定を組み合わせて制御します。 例えば、ローカル・オーサリング環境へのアクセスが必要なユーザーのみが、 ローカル・オーサリング・ポートレットへのアクセスを許可されるようにします。 ユーザーには、すべての項目に対する「読み取り」アクセス権が付与されますが、更新する必要がある項目に対しては「編集」アクセス権のみが付与されます。

Web コンテンツのテスト環境

この環境は UAT テスターによって使用され、サイトおよびコンテンツの更新を配信環境にシンジケートする前にテストできる個々の UAT サーバーのような単純なものである場合もありますし、 サイトおよびコンテンツの更新の検討と配信環境のパフォーマンスのテストの両方で UAT が行われる可能性がある、配信環境の完全なレプリカのような複雑なものである場合もあります。 さらに、単一のバッチで変更を配信環境にシンジケートする前に、オーサリング環境での変更を累積するためにも使用できます。

オーサリング環境内でのサイト・テスト

テスト環境をオーサリング環境に追加すると、コンテンツ管理システムおよび Web サイトでユーザー受け入れテストを実行できるようになります。

オーサリング環境内でテストする場合、UAT サーバーはオーサリング・サーバーとペアになります。
UAT サーバーは配信環境をシミュレートし、Web サイトへの大きな変更をテストするために使用されます。

ステージング環境内でのシステム・テスト

変更を稼働中の配信環境にシンジケートする前に、配信環境のレプリカでシステム・テストを実行できます。

ステージング環境内でテストする場合、オーサリング環境からのデータは、ユーザー受け入れテストが実行されるステージング・サーバーにシンジケートされます。
すべてのテストにパスすると、データはステージング・サーバーから配信環境にシンジケートされます。

Web コンテンツの配信環境

配信環境は、コンテンツを Web サイト・ビューアーに配信するために使用します。

事前レンダリングされた配信

Web サイト全体を HTML に事前レンダリングし、ディスクに保存することができます。 事前レンダリングされたサイトは、その後、表示サイトとして使用でき、Web Content Management または Web サーバーのいずれかを使用してユーザー向けに表示することができます。ポートレットなどの使用している WebSphere Portal の機能が 1 つもなく、コンテンツが静的で、定期的にしか更新されない場合には、事前レンダリングされたサイトをデプロイします。

事前レンダリングされた配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは静的 HTML ファイルのセットに変換されます。
HTML ファイルは、Web サーバー経由でユーザーに表示されます。

サーブレット配信

ユーザーは、Web Content Management サーブレットを使用して表示されるコンテンツにアクセスできます。 オーサリング・ツールなど、ポートレット・ベースの機能を使用する必要がない場合は、サーブレットが配信する Web サイトが使用されます。

サーブレット配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは、Web Content Management サーブレットによって表示され、Web サーバー経由でユーザーが使用できるようになります。

ローカル Web コンテンツ・ビューアー配信

Web コンテンツ・ビューアーは、Web コンテンツ・ライブラリーからのコンテンツをポータル・ページの一部として表示するポートレットです。表示が単純な場合は単一の Web コンテンツ・ビューアーで十分である場合もありますが、 複数の Web コンテンツ・ビューアーを使用してさまざまなライブラリーからのコンテンツを集約することにより、 より豊富な情報をユーザーに提供することもできます。 ローカル Web コンテンツ・ビュー・ポートレットを使用して、Web コンテンツ配信環境に含まれるコンテンツを表示します。

ローカル Web コンテンツ・ビューアーを使用する配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは、ポータル内の Web コンテンツ・ビューアー・ポートレットによってユーザーに表示されます。
ローカル Web コンテンツ・ビューアーを使用する場合、Web コンテンツ・ビューアーは Web Content Management と同じサーバーにインストールされます。

リモート Web コンテンツ・ビューアー配信

JSR 286 Web コンテンツ・ビューアーの WSRP サポートは、リモート WebSphere Portal サーバーまたはクラスター上のコンテンツを表示するために使用されます。

リモート Web コンテンツ・ビューアーを使用する配信環境では、コンテンツはオーサリング・サーバーから配信環境の Web Content Management サーバーにシンジケートされます。JSR 286 Web コンテンツ・ビューアーは Web Content Management サーバーにインストールされ、配信環境の別のポータル・サーバーにインストールされた WSRP プロキシー・ポートレットと通信するように構成されます。
ユーザーは、通常は Web サーバー経由でリモート・ポータル・サーバー上のプロキシー・ポートレットにアクセスすることによって、Web コンテンツを表示します。

Web サーバー

デフォルトでは、IBM WebSphere PortalIBM WebSphere Application Server 内の内部 HTTP トランスポートを使用して、リクエストを処理します。 ただし、WebSphere Application Server では外部 Web サーバーの使用もサポートされているため、ご使用の Web サーバーから WebSphere Portal にアクセスすることができます。 WebSphere Portal と同じマシン上のローカル Web サーバーを使用することも、別のマシン上のリモート Web サーバーを使用することもできます。 リモート Web サーバーは通常、実稼働環境または他の高トラフィック構成のために使用します。また通常は、ポータル・ポートを保護するファイアウォールの外部の非武装地帯 (DMZ) に配置されます。

Web サーバーとWebSphere Application Server 間の通信を使用可能にするには、Web サーバー・プラグインが必要です。 Web サーバー・プラグインによって、リクエストが Web サーバーまたはアプリケーション・サーバーのいずれで処理されるかが決定されます。 このプラグインは、WebSphere Application Server と同じマシンまたは、別のマシンにある Web サーバーにインストールできます。 Web サーバー・プラグインは、プラグインを介してアクセス可能になった WebSphere Application Server への リクエストを処理したり、渡したりする方法を記述した設定を含む XML 構成ファイル (plugin-cfg.xml) を使用します。

WebSphere Application Server の管理コンソールでは、Web サーバーが固有のサーバー・タイプとして表示されるため、Web サーバー・プラグインの plugin-cfg.xml ファイルで使用されているすべての構成プロパティーを管理コンソールから表示して変更できます。

注: 一部のポータル機能が作動するためには、HTTP 操作の POST、PUT、および DELETE が使用可能になるように、Web サーバーで書き込み操作と削除操作が許可されていることを確認する必要があります。 例えば、マッシュアップ統合の場合にそれが必要になります。

i ユーザー: i システムでの外部 Web サーバーの使用について詳しくは、このページにリストされているステップに加えて、Web サーバーのトポロジー・ダイアグラムおよびロードマップの選択も参照してください。

スタンドアロンまたはクラスター環境における別の HTTP ポートを経由した WebSphere Portal へのアクセス

デフォルトでは、WebSphere Portal は、WebSphere Application Server 内の内部の HTTP ポートを経由してアクセスするように構成されています。例えば、http://hostname.example.com:10039/wps/portal。ここで、hostname.example.com は WebSphere Portal が稼働しているマシンの完全修飾ホスト名、10039 は WebSphere Application Server が作成したデフォルトのトランスポート・ポートです。ポート番号はご使用の環境によっては違うことがあります。WebSphere Portal が使用するデフォルトのホスト名およびポートは、wkplc.properties ファイル内の WpsHostName および WpsHostPort プロパティーで指定されます。

外部 Web サーバーを使用するように WebSphere Portal を構成すると、ポータルにアクセスする際には、Web サーバーのホスト名およびポート (例えば 80) を使用します。 スタンドアロン・サーバーまたは垂直クラスター・メンバーの場合、WebSphere Application Server 構成に、ポート 10039 に対応する仮想ホスト定義が存在していなければ、WebSphere Portal のホスト名およびポート (例えば 10039) を使用してポータルにアクセスすることはできません。

WebSphere Portal 構成タスクの多くは、wkplc.properties ファイルの WpsHostName および WpsHostPort プロパティーを使用します。これらのプロパティー値によって指定されるホスト名およびポートを使用して、WebSphere Portal にアクセスできることを保証する必要があります。 これは、以下の 2 つの方法のいずれかを使用して実行できます。
  • WpsHostName および WpsHostPort プロパティー値を変更して、Web サーバーのホスト名およびポートを指定する。
  • 以下で説明しているように、適切な仮想ホスト定義を追加する。
Web サーバーとは異なるホスト名およびポートを使用して WebSphere Portal にアクセスする場合は、WebSphere Application Server 管理コンソールを使用して、必要な仮想ホスト定義を追加します。クラスター環境で Web サーバーを使用している場合は、デプロイメント・マネージャーの管理コンソールを使用して、以下のステップを実行します。
  1. 「環境」 > 「仮想ホスト」を選択する。
  2. default_host の項目または WebSphere Portal アプリケーションへのアクセスに使用されている仮想ホストの項目を選択する。
  3. 「ホスト別名」を選択し、WebSphere Portal へのアクセスに使用される値に対応するホスト名およびポートの項目が存在しているかどうかを確認する (例えば、*:10039)。 その項目が存在していない場合は、「新規作成」を選択して、使用するホスト名およびポートの情報を入力する。
  4. 変更内容を保管する。
  5. Web サーバー・プラグインを再生成する。
  6. リモート Web サーバーを使用している場合は、更新済みの plugin-cfg.xml ファイルを Web サーバー・マシンにコピーする。
  7. 負荷の下でシステムを実行しており、要求が「ServerIOTimeout」のデフォルト値よりも時間が長くかかると予期される場合、この値を増やして要求が 2 回送信されるのを防ぐ。
  8. Web サーバーおよびポータルをリサイクルする。
  9. クラスター環境でノードを再同期し、クラスターを再始動する。

クラスター環境の Web サーバーに関する考慮事項

クラスター環境で Web サーバーと WebSphere Portal を連動させる場合に該当する考慮事項は、以下のとおりです。
  • デプロイメント・マネージャー・システムで configureweb_server_name スクリプトを実行する場合は、Web サーバーとクラスター・メンバーとの間の通信を正しく行うために、クラスターを同期化して再始動する必要があります。
  • スタンドアロン WebSphere Portal ノードが以前に Web サーバー用に構成されていて、その後デプロイメント・マネージャーによって管理されるセルに統合された場合、そのノード上の Web サーバー定義が削除されます。 クラスターで Web サーバーを使用する場合は、ノードを統合してから、デプロイメント・マネージャーの管理コンソールで Web サーバー定義を再作成する必要があります。

データベースに関する考慮事項

単純な開発環境では、Apache Derby を使用したすぐに使用可能なデータベース構成を利用することができます。 Derby と共にインストールすると、IBM WebSphere Portal を PoC (概念検証) 環境に素早くインストールして稼働させることができます。 実稼働環境では、サポートされる他のデータベース管理システムの 1 つを使用する必要があります。

データ・ストレージとフェイルオーバーは、ネットワーク環境が複雑になるにしたがってより複雑になります。 複雑かつハイ・デマンドな環境では、大容量ストレージおよびフェイルオーバー構成のため、データが複数のデータベース・サーバーにわたって分散される可能性があります。 例えば、実稼働環境において、ハイ・デマンド状態で即時に応答する必要があると同時に、複数のデータベース・サーバーにわたって分散されるフェイルオーバー機能の必要がある場合、より堅固なサーバーへデータベースを転送する必要が生じます。 したがって、Derby の使用の制約を認識して、別のデータベースへの転送が環境の容量とスケーラビリティーにどのような影響を与えるかを判断してください。 また、WebSphere Portal により提供される Derby のバージョンに存在するストレスおよびフェイルオーバーの制約が、Derby の今後のリリースにおけるパフォーマンスの改善で解決される見込みがあることをも考慮に入れてください。

Derby は占有スペースが小さい、組み込み Java データベースであり、自己チューニングが可能です。データベースを隠す必要のあるソリューションに最適です。Derby は、ポートレット開発やテスト環境、PoC (概念検証) 環境など、ユーザー数が少ない非クラスターの環境で動作します。

デフォルトでインストールされる Derby データベースは、実稼働環境での使用や Web コンテンツのオーサリングを想定していません。1 つのデータベースの使用がサポートされていますが、パフォーマンスおよび可用性を向上させるためには、複数のデータベースを使用してください。Derby では、クラスター環境、データベース専用モードでのセキュリティーの使用可能化、または複数のアプリケーション・サーバーが単一サーバー上に構成される垂直方向に複製された環境はサポートされません。 実稼働環境や Web コンテンツのオーサリングの場合には、サポートされる他のデータベースのいずれかを使用してください。それらのデータベースは、大容量のデータをより適切に処理し、パフォーマンスが高まるように調整することができるからです。

適切なチューニングによって、他のデータベースでのパフォーマンス向上が可能です。 他のデータベースでは、垂直方向および水平方向のクラスターおよびクローン作成がサポートされています。パフォーマンスおよび可用性を向上させるために、複数のデータベースを使用してください。

サポートされている他のデータベースにデータを転送する場合は、ポータルを広範囲に使用する前にデータベース転送を実行します。Java ヒープ・サイズが十分な大きさでない場合、データベース内のデータが大量であると、データベース転送が失敗する場合があります。 ポータルを使用するにつれて情報がデータベースに追加されるため、大容量データを保管する必要があり、フェイルオーバーが必要であることに気付いたなら、直ちにデータベース転送を実行してください。 データベースの転送を後回しにせず直ちに実行すれば、後の段階で大容量データを、サポートされる他のデータベースに転送することにより生じる一般的な問題 (例えば、Java ヒープ・サイズの不足など) を回避できます。

Derby データベースからデータを転送することはできますが、Derby データベースにデータを転送することはできません。デフォルト・データベース以外のデータベースから転送する場合は、データベース転送機能を試行する前に追加のステップとして、wkplc_sourceDb.properties、wkplc_dbdomain、および wkplc_dbtype.properties ファイルを編集して、ソース・データベース情報を更新する必要があります。

データベース・ユーザー

データベース・ユーザーには、データベース構成ユーザーとデータベース・ランタイム・ユーザー という 2 つのタイプがあります。各ユーザー・タイプが IBM WebSphere Portal の データベース・ドメインで作業するために必要な特権、およびデータベース構成ユーザーを作成して特権を付与するためのコマンドを 理解します。

データベース構成ユーザー

通常、データベース管理システム (DBMS) のインストール時に作成される データベース管理ユーザーは、データベース・インストール・ユーザー またはデータベース構成ユーザー です。データベース構成ユーザーは、 データベース管理システムのインストール時にデフォルトで作成されるユーザーとは限りません。 デフォルト・ユーザーが、データベース構成ユーザーとして使用される場合もあります。 データベース構成ユーザーは、 WebSphere Portal により構成タスクのために使用され、 WebSphere Portal で必要なデータベース構成を作成します。例えば、 データベース構成ユーザーはデータベース表や索引を作成したり、データベース転送を実行したりすることができ、 さらに、データベース管理システムによっては、オペレーティング・システムの特権を保持していることもよくあります。

データベース・ランタイム・ユーザー

データベース・ランタイム・ユーザー の持つ特権は、データベース構成ユーザーに比べて限られています。 ランタイム・ユーザーはデータベースのデータ・ソースに対するランタイム・アクセス権を持ち、 データ上で基本的な読み取りおよび書き込み操作を実行できます。 WebSphere Portal のデータベース・ドメインごとに、 専用のランタイム・ユーザーを作成することを検討してください。ランタイム・ユーザーを作成しない場合は、 WebSphere Portal は構成ユーザーを使用して、ランタイムでデータベースに 接続します。

データベース・ユーザーの特権

以下の表に、 2 つのタイプのデータベース・ユーザー (構成ユーザーとランタイム・ユーザー) が機能を修正するために 必要とする最小限の特権を示します。 リストされた特権は、すべての WebSphere Portal データベース・ドメインに当てはまります。

表 4. データベース・ランタイム・ユーザーがすべてのデータベース・ドメインに対して保持する 最小限の特権リスト
データベース・ドメイン内のアクセス権 Release Community Customization JCR Feedback Likeminds
データベースへのアクセス権 はい はい はい はい はい はい
すべての表での読み取り はい はい はい はい はい はい
すべての表での書き込み はい はい はい はい はい はい
すべての表でのアップデート はい はい はい はい はい はい
すべての表での削除 はい はい はい はい はい はい
表の作成 いいえ いいえ いいえ はい いいえ いいえ
索引の作成 いいえ いいえ いいえ はい いいえ いいえ
シーケンスの使用 いいえ いいえ いいえ はい はい いいえ
表 5. データベース構成ユーザーがすべてのデータベース・ドメインに対して保持する 特権のリスト
データベース・ドメイン内のアクセス権 Release Community Customization JCR Feedback Likeminds
データベースへのアクセス権 はい はい はい はい はい はい
すべての表での読み取り はい はい はい はい はい はい
すべての表での書き込み はい はい はい はい はい はい
すべての表でのアップデート はい はい はい はい はい はい
すべての表での削除 はい はい はい はい はい はい
新規オブジェクト作成用のディスク上の割り当て量 はい はい はい はい はい はい
表スペースの作成 はい はい はい はい はい はい
表スペースの除去 はい はい はい はい はい はい
表の作成 はい はい はい はい はい はい
表の変更 はい はい はい はい はい はい
表の除去 はい はい はい はい はい はい
索引の作成 はい はい はい はい はい はい
索引の除去 はい はい はい はい はい はい
トリガーの作成 はい はい はい はい はい はい
トリガーの除去 はい はい はい はい はい はい
シーケンスの作成 いいえ いいえ いいえ はい はい いいえ
シーケンスの使用 いいえ いいえ いいえ はい はい いいえ
タイプの作成 いいえ いいえ いいえ はい いいえ いいえ
タイプの除去 いいえ いいえ いいえ はい いいえ いいえ
ビューの作成 いいえ いいえ いいえ はい いいえ いいえ
ビューの除去 いいえ いいえ いいえ はい いいえ いいえ

データベース・トポロジー

データベース構成オプションを、ご使用の IBM WebSphere Portal デプロイメント・シナリオと関連させて検討します。 Derby を使用した PoC (概念検証) 環境から、垂直方向および水平方向のクラスター化技法を使用したシステムへ拡大するにつれて、ネットワーク・トポロジーがより複雑になります。

WebSphere Portal データは、PoC (概念検証) および実稼働環境用のデプロイメント・シナリオに応じて、さまざまな可用性の要件を満たすために、単一ストアで構成することも、複数のデータベース・ドメインに編成することもできます。 WebSphere Portal により提供されるデータベース・ドメインにより、ポータル・データを分類して分散させることができます。 効率的な保守のため、各データベース・ドメインを個別のデータベースに配置できます。 さらに、各ドメインを個別のデータベース・サーバー・システムに配置すると、パフォーマンスを最大にできます。

図 1. データベースをセットアップするためのオプション
データベース構成オプションのトポロジー図
ご使用のポータル・デプロイメントでは、PoC (概念検証) 環境用のローカル・データベースが必要か、通常のロード・バランシングをサポートするためにデータベース・ドメインを共有するリモート・データベースが必要か、データを分離する大容量で重いロード・バランシング用のリモート・データベースが必要か、またはこれらデータベース構成を組み合わせることが必要かを検討します。
ローカル・データベースを使用した PoC (概念検証) デプロイメント
データベース・サーバーを WebSphere Portal と同じサーバー・マシンにインストールできます。 これは一般にローカル・データベースと呼ばれます。 ローカル・データベースを使用すると、環境の管理がより容易になります。ただし、このセットアップは PoC デプロイメントの場合にのみ使用するのが最善です。 なぜなら、ローカル・データベースは、サーバー・リソースの使用でポータルと競合し、ポータル環境全体における Single Point of Failure となってしまうからです。
1 つ以上のリモート・データベースを使用した、通常のロード・バランシング
データベース・サーバーを WebSphere Portal とは異なるサーバー・マシンにインストールできます。 これは一般にリモート・データベースと呼ばれます。 リモート・データベースを使用すると、ネットワークの速度に応じて、パフォーマンス上の利点が生じる可能性があります。 複数の生産ラインが関与し、各生産ラインがサーバーのクラスターとして 実装されている場合は、データベース・ドメインを共用することにより、生産ライン全体で、データが確実に自動的 に同期されるようになります。 効率的な保守のため、各データベース・ドメインを個別のデータベースに配置できます。
1 つ以上のリモート・データベースを使用した、大容量のロード・バランシング
大規模でハイ・デマンドの環境にポータルをデプロイする場合は、1 つのサーバーをデータベース・トランザクション専用に指定できます。 ポータルにアクセスするユーザーが増加すると、ポータル・アプリケーションは、データベースを頻繁に使用するようになります。 データベース・アクティビティーによって、CPU 使用率やディスク入出力時間が増大する可能性があります。 データベースをポータルが実行されるサーバーから分離することによって、サーバーの能力が向上します。 各ドメインを個別のデータベース・サーバー・システムに配置すると、パフォーマンスを最大にできます。
要確認: リモート・システムにデータベース・サーバーをインストールする場合は、ポータルがリモート・データベース・サーバーと通信できるようにするために、WebSphere Portal システムにデータベース・クライアント・ソフトウェアをインストールする必要があります。

共用データベース・ドメイン

データベース・ドメインは、ポータル・データの配布方法を分類して判別するのに役立ちます。データの可用性を最大化するには、複数のデータベースにわたってポータル・データを配布することができます。またドメインによっては、複数の実動ライン間でデータを共用することができます。単一データベース・ドメインを転送するか、または複数ドメインを転送するかを選択できます。

データを分離することにより、各カテゴリーのデータを専用のデータベース・テーブル・セットまたはファイル・システムに保管できます。ポータル・リソースのデータベース・テーブルとスキーマのセットをデータベース・ドメインと言います。 データベース・ドメインは、カテゴリーごとのストレージとデータ転送をサポートしています (例えば、Configuration、Release、Customization、Community、IBM Java Content Repository (JCR) など)。 データを分離することによって、複数のポータルでドメインを共有できるようになります。 さらに、さまざまなデータベース・タイプにさまざまなドメインを分散させることもできます。 例えば、LikeMinds のデータをデフォルト・データベースに残し、 他のすべてのデータを別のデータベースに移動することが可能です。このようなドメインの分離に基づいて、実動ノードを別々のクラスターに分割する実動環境をサポートできます。 例えば、各クラスターは独立して稼働可能ですが、同じ Community データベース・ドメインと Customization データベース・ドメインを共有します。これらのクラスターのそれぞれを実動ラインと言います。

データベース・ドメインでは、ポータル・データが以下のカテゴリーとサブカテゴリーに分類されており、さまざまなデータベースにポータル・データを配布する方法を決定しやすくしています。
Configuration データ
このデータで、データベース接続、オブジェクト・ファクトリー、デプロイメント記述子などの Portal Server セットアップを定義します。このタイプのデータは、通常、サーバー・ノードが動作している間は一定です。 構成データは通常、プロパティー・ファイルに保存され、ファイル・システムのセキ ュリティーまたはアプリケーション・サーバーの管理権限によって保護されます。
Release データ
このデータの内容は、外部で設計後、ステージング・プロセスによってポータルに取り込んだ、ポータル・コンテンツのすべての定義、ルール、および権限です。ページ階層、使用可能なポートレットおよびテーマ、テンプレート、クリデンシャル・スロット、Personalization ルール、ポリシーなどがあります。 これらのリソースは通常、実動 システムでは変更されません。変更には管理権限が必要です。アドミニストレーターは通常、統合サーバーで Release データを作成し、実動システムにステージングします。Release データは アクセス制御によって保護されており、データのみでコードは含みません。 複数の実動系統からなる環境では、クラスターごとに Release データのコピーが 1 つずつ存在します。Release データには、以下の 2 つの個別のドメインが含まれます。
  • Release: アクセス制御、ページ、ポートレットなど、ポータルの静的サイト構成が含まれます。
  • JCR: オーサリングされたコンテンツ、Personalization ルール、およびテーマ・ポリシー定義が含まれます。
これらはリリース・データと見なされ、個別に実動ラインへプロモートする必要があります。
Customization データ
このデータは、特定ユーザーだけに関連したデータであり、ユーザー間またはユーザー・グループ間で共有することはできません。典型的な例としては、ポートレット・データやカスタマイズされたページ (暗黙派生ページ) などがあります。このデータの有効範囲は単一ユーザーのみに限定 されているので、アクセス制御による保護も簡略化されています。
複数の実動系統からなる環境では、それらの実動系統間で共用されるデータベースに Customization データが保管されます。したがって、それらの実動ラインの間では、データが自動的に同期します。
Community データ
このデータには、複合アプリケーション・インスタンスなどの、通常、実稼働時に変更されるリソースがすべて含まれています。通常、ユーザーやグループは、共用リソースの変更や削除を行うことができます。コミュニティー・リソースはアクセス制御によって保護されます。
以下の表に、サポートされるデータベース・ドメイン、ドメインが共用可能かどうか、およびその保管方法をリストします。
表 6. サポートされるデータベース・ドメイン
データベース・ドメイン 共用可能 ストレージ方式
Release 不可 データベース
Customization データベース
Community データベース
JCR 不可 データベース
Feedback データベース
LikeMinds データベース

保守とステージングのために、1 つの実動ラインをサービス休止状態にしながら、他のラインでは、古いデータに基づいて要求への対応を続けることも可能です。最初の実動ラインを更新してサービス中の状態に戻したら、2 番目のラインを同じ方法で更新します。 共用ドメイン内のデータの更新は、他の実動ラインに影響を 与えるので、重大な意味を持ちます。

アプリケーションのアベイラビリティーに影響を与えずに、個々のサーバーを実稼働から切り離すことができるように、 環境全体のキャパシティーは想定される使用率よりも大きくしておく必要があります。 ポータルがすべてのシステム・リソースを確実に使用できるようにするには、実動システムはポータル専用にして 、ポータルには関係のないその他のサーバー・ソフトウェアを実行しないようにする必要があります。

メンテナンスの目的で、以下のデータベース・ドメインをオフラインにすることができます。
  • Community
  • Customization
  • Feedback
  • LikeMinds
WebSphere Portal を始動する際はいつでも、以下のデータベースをオフラインにしないでください。
  • Release
  • JCR
オフラインのデータベース・ドメインがある間は、その該当するデータに WebSphere Portal がアクセスできないため、エラー・メッセージが表示される可能性があります。WebSphere Portal 自体は、反応できる状態にあります。データベース・ドメインが再び使用可能になると WebSphere Portal は、この使用可能状態を検知し、再接続し、該当するデータの処理を続行します。共用データベースのデータは、常時その時点で使用中の実動ラインから使用可能であることが必須のため、共用データベースが定期保守の影響を受けてはなりません。
VMM データベースの共用

リポジトリー全体およびプロパティー拡張のための VMM データベースは、複数の生産ラインで共用できます。 VMM データベースがサービス休止している場合、WebSphere Portal は機能しません。

データベースの互換性に関する考慮事項

データベース管理者である場合は、IBM WebSphere Portal のデータベース要件について考慮する必要があります。

始める前に
IBM i オペレーティング・システムで稼働する IBM WebSphere Portal でのデータベース互換性は、以下のように相互に排他的であることに注意してください。
  • IBM DB2 Universal Database™ for iSeries® データベースは、WebSphere Portal for i でのみサポートされています。
  • WebSphere Portal でサポートされているその他のデータベース管理システムは、任意のポータル・プラットフォームで動作するよう構成できます。
このタスクについて

Windows での DB2 の計画

IBM DB2 Universal Database Enterprise Server Edition へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • WebSphere Portal では、DB2 JDBC タイプ 2 (CLI ベース) およびタイプ 4 (JCC) の各ドライバーがサポートされています。
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

  • 同一のデータベース・ユーザー ID を使用する場合は、データベース名、データベース・サーバー・ノード、またはスキーマ名を固有にする必要があります。
  • DB2 Universal JDBC ドライバー (タイプ 4 モード) を使用する場合、データベースに直接接続してください。 別名データベース (ゲートウェイ) に接続するのではなく、JDBC 接続 URL (dbdomain.DbUrl) およびデータベース名プロパティー (dbdomain.DbName) には実際のデータベース名を指定してください。

ローカル・データベース環境では、WebSphere PortalDB2 は同じシステムにインストールします。

図 2. ローカル・データベース環境
ローカル・データベース。この図について詳しくは、このトピックのテキストを参照してください。

図 2 に示すように、JDBC タイプ 2 接続を使用する場合、WebSphere Portal および DB2 Connect は 1 つのシステム (ローカル・システム) にインストールします。 DB2 サーバーは別のシステム (リモート・システム) にインストールします。

図 3. リモート・データベース環境 (JDBC タイプ 2 接続)
リモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。

JDBC タイプ 4 接続の場合、WebSphere Portal を実行する システムに DB2 Connect をインストールする必要はありません。 図 3 に示すように、DB2 に付属している DB2 Universal JDBC ドライバーは、このシステムにコピーされます。 これは、WebSphere Portal の Java 仮想マシン内で使用され、 リモートの DB2 サーバーに直接接続します。

図 4. リモート・データベース環境 (JDBC タイプ 4 接続)
タイプ 4 接続を行うリモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。
手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。 アーキテクチャーによって、これらのデータベースはそれぞれ、1 つまたは 複数のインスタンスに存在することができます。 ただし、推奨されるアーキテクチャーは、インストール・プログラムによって作成されたデフォルト・インスタンス (db2inst1) を使用します。
    表 7. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 8. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

UNIX または Linux での DB2 の計画

IBM DB2 Universal Database Enterprise Server Edition へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • WebSphere Portal では、DB2 JDBC タイプ 2 (CLI ベース) およびタイプ 4 (JCC) の各ドライバーがサポートされています。
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

  • 同一のデータベース・ユーザー ID を使用する場合は、データベース名、データベース・サーバー・ノード、またはスキーマ名を固有にする必要があります。
  • ローカルな DB2 データベースにアクセスすると、共用メモリーの問題が発生する場合があります。この問題を解決するには、ローカル・システム上のリモート・データベースとしてローカル・データベースを扱う必要があります。 手動でデータベースを作成する場合は、『リモート・データベースの作成』セクションの指示に従ってください。
  • DB2 Universal JDBC ドライバー (タイプ 4 モード) を使用する場合、データベースに直接接続してください。 別名データベース (ゲートウェイ) に接続するのではなく、JDBC 接続 URL (dbdomain.DbUrl) およびデータベース名プロパティー (dbdomain.DbName) には実際のデータベース名を指定してください。

ローカル・データベース環境では、WebSphere PortalDB2 は同じシステムにインストールします。

図 5. ローカル・データベース環境
ローカル・データベース。この図について詳しくは、このトピックのテキストを参照してください。

図 2 に示すように、JDBC タイプ 2 接続を使用する場合、WebSphere Portal および DB2 Connect は 1 つのシステム (ローカル・システム) にインストールします。 DB2 サーバーは別のシステム (リモート・システム) にインストールします。

図 6. リモート・データベース環境 (JDBC タイプ 2 接続)
リモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。

JDBC タイプ 4 接続の場合、WebSphere Portal を実行する システムに DB2 Connect をインストールする必要はありません。 図 3 に示すように、DB2 に付属している DB2 Universal JDBC ドライバーは、このシステムにコピーされます。 これは、WebSphere Portal の Java 仮想マシン内で使用され、 リモートの DB2 サーバーに直接接続します。

図 7. リモート・データベース環境 (JDBC タイプ 4 接続)
タイプ 4 接続を行うリモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。
手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。 アーキテクチャーによって、これらのデータベースはそれぞれ、1 つまたは 複数のインスタンスに存在することができます。 ただし、推奨されるアーキテクチャーは、インストール・プログラムによって作成されたデフォルト・インスタンス (db2inst1) を使用します。
    表 9. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 10. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

IBM DB2 for i の計画

IBM DB2 for i へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • デフォルトのデータベース接続はタイプ 4 接続であるため、IBM i コマンド WRKRDBDIRE を使用して、ローカル・データベース環境のデータベース項目、またはリモート環境でのリモート・データベースのデータベース項目があることを確認します。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

DB2i に統合されていますが、必要なデータベースとユーザ ーを作成し、そのユーザーに適切な権限を付与することは必要です。 WebSphere Portal によってデータベースを作成することも可能です。

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

WebSphere Portal はインストール時に ApacheDerby を使用します。また、 IBM System i5 システム用の DB2 の構成をサポートしています。Derby データベースは、テスト環境に最適です。実稼働環境の場合は、インストール済みの Derby データベースを IBM DB2 for i に移行できます。ただし、Derby へ転送して戻すというオプションはないということに注意してください。

IBM DB2 for i データベースを使用す れば、アプリケーションまたはユーザー・インターフェースを使用して、サーバー・データへのアクセスと管理を実行で きます。IBM DB2 Universal Database for i は、データへのアクセスと保護の機能を提供するだけでなく、参照保全性や並列データベース処理などの拡張機能も提供 しています。

IBM DB2 for i は、 i システムに完全に統合されたリレーショナル・データベース・マネージャーです。IBM DB2 for i には、広範囲のアプリケーション・タイプに対応する、トリガー、ストアード・プロシージャー、動的ビットマップ索引付けなどの機能も用意されています。 対応するアプリケーションの範囲は、クライアント/サーバー・ソリューションに対する従来の ホスト・ベースのアプリケーションから、ビジネス・インテリジェンス・アプリケーションまでの 広い範囲にわたります。

DB2 Query Manager および SQL (構造化照会言語) Development Kit for System i5 は、IBM DB2 for i に対するインターフェースとして、対話式の照会とレポート作成のインターフェース、および高水準プログラム言語で SQL アプリケーション・プログラムを作成する際に役立つプリコンパイラーとツールを追加します。OS/400 用の SQL インプリメンテーションは、 i データの定義、操作、照会、およびアクセス制御を実行できます。このインプリメンテーションでは、 i ファイルでも SQL テーブルでも同じように操作できます。

1 つのデータベースを使用して、WebSphere PortalMember Manager、 および content publishing のすべての情報を保持するようにする場合、必要なユーザー・プロファイルは 1 つだけです。 複数の i システムを使用する場合や、個別のデータベースが必要な場合にのみ、追加のユーザー・プロファイルが必要になります。

WebSphere Portal は、データベースを作成するときに、UserData ディレクトリー wp_profile_root/ConfigEngine/properties にある wkplc_dbdomain.properties ファイルに指定されているデータベース名を使用します。 wkplc_dbdomain.properties ファイルに異なる値を設定することで、異なるデータベースを最大 6 つまで作成できます。

ポータルを 1 つのデータベースを使用するように構成することは技術的に可能ですが、 スケーラビリティーとパフォーマンスの調整上の理由から、別々のデータベースを使用します。 単一の共用データベースを使用するには、各データベースとユーザー変数を、 それぞれ、ご使用のデータベース名とデータベース・ユーザーで置き換えます。
注: データベース名のフォーマットは、タイプ 2 データベース接続の場合は *LOCAL/database_name となり、タイプ 4 データベース接続の場合は myserver.mycompany.com/database_name などの完全修飾サーバー名になります。

ローカル・データベース環境では、WebSphere Portal および IBM DB2 for i に、タイプ 4 接続またはタイプ 2 接続でアクセスできます。 タイプ 4 がデフォルトで、推奨の接続です。

リモート・データベース環境では、WebSphere Portal は、DB2 サーバーに直接接続されます (JDBC タイプ 4 接続)。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。
    表 11. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 12. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

DB2 for z/OS の計画

IBM DB2 Universal Database for z/OS® へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に

WebSphere Portal 用のデータベースとして使用するために DB2 for z/OS のインストールを計画しているときは、以下を検討してください。

  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
  • Java Database Connectivity の要件を満たしていることを確認します。以下のリファレンスを参照してください。
  • IBM DB2 Universal Database for z/OS を、データベース・ユーザー・レジストリーまたはプロパティー拡張 (索引) データベースとして使用してデータベース転送を行う予定である場合は、共通サービス域 (CSA) 設定を 3500,350000 に変更します。CSA の計算および設定について詳しくは、該当する以下の DB2 for z/OS Information Center のトピックを参照してください。
  • DB2 for z/OS バージョン 9.1.2 と共にタイプ 2 ドライバーを使用する予定である場合は、DB2 for z/OS APAR PK58105 がインストール済みであることを確認してください。
  • 以下のガイドラインを検討してください。
    • 現行バージョンと旧バージョンの WebSphere Portal が混在して同じ DB2 for z/OS サブシステムを使用している場合は、現行バージョンの WebSphere Portal のデータベース・ユーザー ID を旧バージョンの ID とは異なるように設定し、インストール時の競合を避ける必要があります。 2 つのバージョンの WebSphere Portal が 2 つの異なる DB2 for z/OS サブシステムに接続する場合は、同じユーザー ID を使用しても競合は発生しません。
    • システムのバッファー・プール割り振りを確認し、ご使用のインストールに応じて適切にバッファー・プールを定義し、十分な大きさのサイズを定義してください。例えば、以下のようにします。
      -db2 display bufferpool(bp2) 
      -db2 alter bufferpool(bp2) vpsize(15000)
      • 必要に応じて、以下のような追加のバッファー・プールで操作を繰り返します。
        • bp3
        • bp4
        • bp5
        • bp32k1
        • bp32k2
      • データベース転送を実行する前に、BP8K0 カタログ・バッファー・プールを 35,000 に更新します。SYSIBM.SYSDATABASE テーブルはこのバッファー・プール内に存在し、データベース転送時に DB2 for z/OS によって広範囲に使用されます。
    • Derby から DB2 for z/OS へのデータ転送時には、文書を保管するデータベース・テーブル用に、サポートしている下位バイト・テーブル・スペースが作成されます。テーブル・スペースの PRIQTY および SECQTY は、 デフォルト値を使用して割り当てられます。多数の文書を保管する場合は、自動クラス選択 (ACS) ルーチンを使用して、 少なくとも 10 シリンダーの 1 次および 2 次スペース割り振りで、DB2 for z/OS データ・セットを割り振るか、または DB2 DSNTIJUZ メンバーの PRIQTY と SEQTY にとって十分に大きな値を指定してください。 テーブル・スペースは、名前 (JCRDB.Sxxxxxxx のような構造) で識別できます。 xxxxxxx は、システムが割り当てる 7 個の数字と文字の組み合わせです。
    • また、メンバー DSNTIJUZ で次のパラメーターを更新してから、DSNTIJUZ が正常に実行されていることを確認します。
      • edmdbdc = 204800
      • edmpool=409600
      • edmstmtc=204800
      • rrulock=no
      • cachedyn=yes (作成済みの動的 SQL ステートメントがキャッシュされる)
      • dbacrvw=yes (データベース管理者によるビューの作成を許可する)
    • LikeMinds サンプルを実行する予定である場合は、NUMLKTS パラメーターおよび NUMLKUS パラメーターを引き上げます。デフォルトの 10 倍で十分ですが、サンプルの使用法によってはさらに引き上げます。例えば、NUMLKTS=1000 および NUMLKUS=10000 がインストールでのデフォルト値である場合は、これらの値を NUMLKTS=10000 および NUMLKUS=100000 に更新します。
    • DB2 JDBC および ODBC メタデータ・メソッドで必要なオブジェクトを作成するために、ジョブ DSNTIJSG が実行されていることを確認します。「DB2 インストール・ガイド」の『JDBC および ODBC サポート用のストアード・プロシージャーとテーブルを使用可能にする』を参照してください。
    • ジョブ DSNTIJMS が正常に実行されていることを確認します (バインドの再実行)。
    • ジョブ DSNTIJEX が正常に実行されていることを確認します。
    • ラージ・オブジェクトが格納されて列が非常に大規模になる可能性があるため、これらの列に対する変更をロギングするには、大容量のログ・スペースが必要になります。したがって、そのようなデータを格納するテーブル・スペースでは、ラージ・オブジェクト (LOB) ロギングはデフォルトで無効になっています。LOB ロギングが無効の場合、フルバックアップのリカバリーは可能ですが、ポイント・イン・タイム・リカバリーに使用できる増分バックアップのリカバリーは不可能です。ポイント・イン・タイム・バックアップをリカバリーするには、LOB ロギングを有効にする必要があります。詳しくは、技術情報 1306637「Managing LOB logging in DB2 for z/OS」を参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

単一の DB2 for z/OS サブシステムを使用して複数のポータル・インストール済み環境のデータを保持しようとする場合は、同じユーザー名ではあるが、データベース・ドメインごとに異なるスキーマ名を使用します。 Member Manager の場合は、ユーザー名をスキーマ名と一致させる必要があります。このため、2 つの異なるポータル・インストール済み環境の Member Manager データベースに対して、同じデータベース・ユーザーを使用することはできません。

各ポータル・インストールは、別々の WebSphere Application Server セルに存在する必要があります。 ポータルを同一のファイル・システムにインストールする場合、 各ポータルは別々の固有ディレクトリーにインストールする必要があります。 ポータルを異なるファイル・システムにインストールする場合は、 同一のディレクトリー名を使用することができます。

リモート・データベース環境では、WebSphere PortalDB2 Connect が 1 台のマシン (ローカル・マシン) にインストールされ、DB2 for z/OS サーバーは別のマシン (リモート・マシン) にインストールされます。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベース・サブシステムを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal は、1 つのデータベースを使用するように構成できます。しかし、複数の異なるデータベースを使用するなら、スケーラビリティーとパフォーマンスが向上します。
    表 13. アプリケーション、データベース名、および必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    WebSphere Portal の最低限、またはすべてのデータを保持するために使用する。 ページなどのユーザー・カスタマイズに関する情報や、ユーザー・プロファイルおよびログイン情報を保管します。

    • relzos
    • commzos
    • custzos
    WebSphere Portal ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization, Web Content Management

    文書と他のコンテンツ、パーソナライゼーション・ルール、パーソナライゼーション・キャンペーン、および文書ライブラリーの構成情報を含む。

    jcrdbzos Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト・アクティビティーの分析用レポートを生成するために、Web サイトによってログに記録された情報を保管する。

    • データベース: fdbkzos
    • テーブル・スペース: fdbkdbts
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • データベース: lmdbzos
    • テーブル・スペース: lmdbts
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 14. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。
  3. ご使用の Java Content Repository が Declared Global Temporary Table (DGTT) を使用する場合は、使用前に適切な TEMP データベースおよび TEMP テーブル・スペースを構成する必要があります。TEMP データベースには、 割り振られた追加スペースが必要である場合があります。以下の情報をガイドラインとして使用して、 宣言された一時テーブルを含めるための TEMP データベースおよび TEMP テーブル・スペースを作成します。
    表 15. TEMP データベースおよび TEMP テーブル・スペースの作成方法の例 (データベース・バージョン別)
    データベース・バージョン
    DB2 for z/OS バージョン 8 TEMP データベースおよびテーブル・スペースが存在しない場合は作成する。 以下は、TEMP データベース定義の代表例です。
    CREATE DATABASE TEMP AS TEMP STOGROUP SYSDEFLT;
    CREATE TABLESPACE TEMP IN TEMP  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32; 
    このバージョンでは、ソートなどの作業用ストレージを必要とする SQL ステートメント用の 作業ファイル・データベース・ストレージも必要です。 This requires the addition of a table space to support sorting operations in addition to the TEMP database.
    非データ共用環境での DB2 for z/OS バージョン 9 TEMP データベースは DSNDB07 で、データベースのインストール時に作成されます。 一時テーブル・スペースが既存の TEMP データベースに追加されます。 以下は、一時テーブル・スペースの代表例です。
    CREATE TABLESPACE ICMTEMP IN DSNDB07  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32; 

    このバージョンでは、作業ファイル・データベース および TEMP データベースが結合されます。作業ファイル・データベースの作成の手順およびサイズ設定の推奨については、 DB2 for z/OS インフォメーション・センターを参照してください。

    データ共用環境での DB2 for z/OS バージョン 9 WORKFILE データベースを作成します。1 つのサブシステムに作成できる WORKFILE データベースは 1 つだけです。 以下は、 WORKFILE データベースおよび一時テーブル・スペースの作成の代表例です。
    CREATE DATABASE WORKTEMP AS WORKFILE STOGROUP SYSDEFLT;  
    CREATE TABLESPACE ICMTEMP IN WORKTEMP  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32;  

    このバージョンでは、作業ファイル・データベース および TEMP データベースが結合されます。作業ファイル・データベースの作成の手順およびサイズ設定の推奨については、 DB2 for z/OS インフォメーション・センターを参照してください。

    TEMP データベースおよび TEMP テーブル・スペースのセットアップに関する追加情報については、DB2 for z/OS の資料を参照してください。

Oracle の計画

Oracle へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal は、 下記の各データベースに別々のデータベース・ユーザーを選択した場合に 単一の共用データベースを使用するように 構成できます。。Oracle では、 単一のデータベース構成により、データベース管理システムが使用する システム・リソースの消費量を大幅に削減できます。 以下に示すすべてのデータベースについて独立したテーブル・スペースを使用すると、スケーラビリティーおよびパフォーマンスを向上できます。
    表 16. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 17. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

Oracle RAC の計画

Oracle RAC へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

Oracle RAC の デフォルトのテーブル・スペース・サイズは、データベース転送を正常に実行するために、 autoextend をオンにして 1024MB に設定する必要があります。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal は、 下記の各データベースに別々のデータベース・ユーザーを選択した場合に 単一の共用データベースを使用するように 構成できます。Oracle では、 単一のデータベース構成により、データベース管理システムが使用する システム・リソースの消費量を大幅に削減できます。 以下に示すすべてのデータベースについて独立したテーブル・スペースを使用すると、スケーラビリティーおよびパフォーマンスを向上できます。
    表 18. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 19. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

SQL Server の計画

SQL Server へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal でサポートされているかどうかを確認します。 WebSphere Portal の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。
    表 20. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 1 名以上のユーザーを SQL Server インスタンスに接続します。 ユーザーには複数のスキーマ名を使用する権限を付与できるため、各インスタンスに 1 名のユーザーで十分です。
  3. 各スキーマが所有するテーブル数およびオブジェクトのタイプを検討します。 WebSphere Portal アーキテクチャーでは、以下の各スキーマを同じデータベース内に配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。 サイズは、Java Content Repository 関数を使用して増加できます。
    表 21. アプリケーション、データベース・スキーマ・プレースホルダー、推奨される名前、および機能別の情報
    アプリケーション データベース・スキーマ・プレースホルダー 推奨される名前 機能
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    <なし> コア・スキーマ。ドメインごとに、約 130 のテーブルを所有します。ページに対して行われたユーザー・カスタマイズを保管するテーブルを含む、WebSphere Portal コア・オブジェクトを所有しています。
    Java Content Repository icmadmin <なし> Java Content Repository スキーマ。少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback feedback <なし> Feedback スキーマ。ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有します。
    Likeminds LIKEMINDS <なし> LikeMinds スキーマ。Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する、約 15 のテーブ ルを所有します。

ユーザー・レジストリーに関する考慮事項

ユーザー・レジストリーまたはユーザー・リポジトリーでは、認証と許可を含むセキュリティー関連の機能を実行するために、ユーザーが認証され、ユーザーとグループに関する情報が取得されます。

ユーザー・レジストリーには、ユーザー ID やパスワードなどのユーザー・アカウント情報が保管され、認証時にアクセスすることができます。 ユーザー・リポジトリーには、ユーザー・プロファイルとユーザー設定の情報が保管されます。 ユーザー・レジストリーまたはユーザー・リポジトリーは、以下のことを行うために使用されます。
  • 基本認証、ID アサーション、またはクライアント証明書を使用して、ユーザーを認証する
  • ユーザーとグループの情報を取得して、セキュリティー役割へのユーザーとグループのマップなどのセキュリティー関連の管理機能を実行する
IBM WebSphere Portal は、デフォルトでは、組み込みのファイル・リポジトリーが備わった統合リポジトリーと共にインストールされます。 この統合リポジトリーにより、各種ユーザー・レジストリー、仮想ポータルのレルム・サポート、または単一の作業単位を作成するためのプロパティーの拡張を追加することができます。 統合リポジトリーに追加できる使用可能なユーザー・レジストリーは、LDAP ユーザー・レジストリー、データベース・ユーザー・レジストリー、およびカスタム・ユーザー・レジストリーです。
要確認: 組み込みファイル・リポジトリーの使用は、実稼働環境では推奨されません。 別のリポジトリーを追加してそのリポジトリーから管理ユーザーを選択した後、そのファイル・リポジトリーを除去する必要があります。

統合リポジトリーに基づいて、WebSphere Portal は複数のリポジトリー (LDAP、DB、およびカスタム・ユーザー・レジストリーまたはそのいずれか) において統合できるユーザー・ベースを作成できます。 また、企業 LDAP ディレクトリーが読み取り専用になっている場合は、別個のストアで追加属性を定義できます。

統合リポジトリーを使用している場合は、新規ユーザーおよびグループの保管場所を計画する必要があります。 デフォルトで、新規ユーザーおよびグループは、デフォルトのファイル・リポジトリーに保管されます。 複数の LDAP ユーザー・レジストリーおよび (または) データベース・ユーザー・レジストリーを使用している場合は、 新規ユーザーおよびグループの保管場所となるデフォルトのユーザー・レジストリーとして、どのユーザー・レジストリーを定義するかを判別する必要があります。 すべてのユーザー・レジストリーを統合リポジトリーに追加した後、wp-set-entitytypes タスクを実行して、特定のユーザー・レジストリーをデフォルトの場所として設定できます。

要確認: 複数のユーザー・レジストリーを結合する前に、レジストリーで以下の制限事項を確認し、問題があれば訂正してください。
  • レルムにおける識別名は、すべてのレジストリーで固有でなければなりません。例えば、uid=wpsadmin,o=yourco が LDAP1 内に存在する場合は、このユーザーが LDAP2、LDAP3、または DB1 内に存在することはできません。
  • レルムにおける短縮名 (例えば wpsadmin) は、すべてのレジストリーで固有でなければなりません。
  • レルム内で使用されるすべてのレジストリーの基本識別名は重複してはなりません。例えば、LDAP1 が c=us,o=yourco の場合、LDAP2 を o=yourco にしてはなりません。
  • レルム内で使用されるどのレジストリーでも、基本エントリーを空白にしてはなりません。
  • IBM Lotus Domino が複数のレジストリー構成内のユーザー・レジストリーの 1 つになり、別のユーザー・レジストリーとレルムを共有する場合には、グループが必ず、デフォルトのフラット・ネーミング構造ではなく階層フォーマットで Domino Directory に保管されるようにしてください。 例えば、フラット・ネーミング規則は cn=groupName ですが、 階層フォーマットは cn=groupName,o=root です。
  • このユーザーは、プロパティー拡張構成内ではなく、特定のユーザー・レジストリー内に存在している必要があります。 存在していない場合、このユーザーは、レルムのメンバーになることができません。

統合リポジトリーをサポートしないアプリケーションが存在する場合は、スタンドアロンの LDAP ユーザー・レジストリーまたはスタンドアロンのカスタム・ユーザー・レジストリーに切り替えることができます。

ユーザー・レジストリー・オプションの概要

IBM WebSphere Portal には、さまざまなセキュリティー構成タスクがあります。 以前は、タスクは 1 つだけであり、エラーからリカバリーしたり、増大するビジネス要件にユーザー・レジストリーを適合させたりすることはできませんでした。 現在は、複数のタスクがあり、ご使用のシステムを微調整してビジネス要件を満たすことができます。

以下の汎用セキュリティー・オプションを選択できます。
表 22. セキュリティー・オプションとその説明
セキュリティー・オプション 説明
スタンドアロン LDAP セキュリティー このオプションは、単純な単一の LDAP セキュリティー・オプションです。過去に提供されていた LDAP セキュリティー・オプションと類似したものです。 このオプションにより、単一レルムを持つ仮想ポータルを作成して、ユーザーおよびグループを単一の LDAP サーバーに保管できます。
統合セキュリティー このオプションは、単一レルム・サポート・オプションを持つスタンドアロン LDAP ユーザー・レジストリーに対する拡張オプションです。 このオプションにより、複数のレルムを持つ仮想ポータルを作成したり、複数のリポジトリー (LDAP、データベース、カスタム) を使用したり、アプリケーション・グループをシステムに追加したりできます。 このオプションは、複数の LDAP サーバーを 1 つのまとまった構造にマージする必要がある場合に有用です。
重要: 各種リポジトリー間で名前の重複がないよう、特に注意する必要があります。 例えば、「wpsadmin」という名前のポータル管理者が製品をインストールした場合には、「wpsadmin」という名前のユーザーは 企業の LDAP サーバーに存在してはなりません。
カスタム・セキュリティー このオプションによって、Virtual Member Manager (VMM) 用のカスタム・ユーザー・レジストリーおよびカスタム・メンバー・アダプターを提供することにより、完全に制御された WebSphere セキュリティー環境を作成できます。 このオプションの機能は、ご使用の実装環境によって異なります。
スタンドアロン LDAP セキュリティー

出荷時の WebSphere Portal は、組み込みのファイル・リポジトリーが備わったデフォルトの統合リポジトリーで構成されます。 したがって、wp-modify-ldap-securityタスクを実行して、スタンドアロン LDAP ユーザー・レジストリーに切り替える必要があります。 LDAP ユーザー・レジストリーを WebSphere Portal で適正に作動させるため、構成された LDAP サーバーおよびビジネス要件に合うように、属性構成を適応させる必要があります。 これらのタスクのステップが完了すると、セキュリティーは実動の準備ができています。

スタンドアロン LDAP ユーザー・レジストリーを使用後、ユーザー・レジストリーを管理する必要があるかもしれません。以下の任意のオプション・タスクを実行して、スタンドアロン LDAP ユーザー・レジストリーを微調整できます。
表 23. スタンドアロン・ユーザー・レジストリーを管理するオプション・タスク
タスク 説明
スタンドアロン LDAP ユーザー・レジストリーを更新する バインド ID およびパスワードなどの特定のパラメーターを更新して、LDAP ユーザー・レジストリー関連の問題を修正できます。
プロパティー拡張データベース (以前は索引データベースと呼ばれました) このオプションを選択すると、追加属性を LDAP ユーザー・レジストリーではなく、VMM プロパティー拡張内に保管します。 Common Mail ポートレットや IBM Lotus Web Content Management などのアプリケーションは、プロパティー拡張データベースを使用して追加属性を保管します。 プロパティー拡張データベースを使用可能にした後、属性を追加してユーザーのビジネス要件に合わせることができます。
エンティティー・タイプを作成する LDAP ユーザー・レジストリー内ではなく WebSphere Portal 内に存在するエンティティー・タイプを使用する場合は、このオプションを選択します。 このオプションは、ユーザー・レジストリー内でエンティティー・タイプを作成し、WebSphere Portal とユーザー・レジストリー間でエンティティー・タイプをマップする相対識別名 (RDN) を追加します。
既存のエンティティー・タイプを更新する このオプションを選択すると、既存の単一エンティティー・タイプのデフォルトの親を更新します。 例えば、あるリポジトリーを削除したものの、エンティティー・タイプがその削除されたリポジトリーを指している場合、情報を更新して新規リポジトリーを指すようにする必要があります。
統合セキュリティー
出荷時の WebSphere Portal は、組み込みのファイル・リポジトリーが備わったデフォルトの統合リポジトリーで構成されます。 統合リポジトリーは、ユーザーのビジネス要件に適合させ、また要件が増大するにつれてビジネスを容易に拡張できるようにする、最も豊富なオプションを提供します。 例えば、ユーザーの会社が既存 LDAP ユーザー・レジストリーを持つ新規ビジネスを獲得した場合、その LDAP サーバーを統合リポジトリーに追加するだけですみます。 以下のタスクの 1 つを選択して、実動リポジトリーを使用可能にします。
表 24. 実動リポジトリーを使用可能にするタスク
タスク 説明
統合 LDAP リポジトリーを VMM 構成に追加する このオプションを選択すると、LDAP サーバーを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
統合データベース・リポジトリーを VMM 構成に追加する このオプションを選択すると、データベースを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
統合カスタム・ユーザー・レジストリーを追加する このオプションを選択すると、貴社が作成したカスタム・ユーザー・レジストリーを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
初期 LDAP ユーザー・レジストリー、データベース・ユーザー・レジストリー、またはカスタム・ユーザー・レジストリーを追加した後で、追加のユーザー・レジストリーをリポジトリーに追加して、複数のユーザー・レジストリー構成を作成できます。 リポジトリーの構成後、これが開発環境でない限り、デフォルトのファイル・ベース・リポジトリーを除去する必要があります。 以下のタスクは、デフォルトのファイル・ベース・リポジトリーを除去するために必要です。
表 25. デフォルトのファイル・ベース・リポジトリーを除去するために必要なタスク
タスク 説明
ユーザーおよびグループの保管場所となるユーザー・レジストリーを変更する このタスクは、新規ユーザーおよびグループの保管場所であるデフォルトのリポジトリーを変更します。
WebSphere Application Server 管理ユーザーを変更する このタスクは WebSphere Application Server アドミニストレーター・ユーザー ID およびパスワードを、インストール中に定義されたものから、クラスターまたはスタンドアロン実稼働環境に必要な新規ユーザー ID およびパスワードに変更します。
WebSphere Portal Server アドミニストレーターを変更する このタスクは WebSphere Portal アドミニストレーター・ユーザー ID およびパスワードを、インストール中に定義されたものから、クラスターまたはスタンドアロン実稼働環境に必要な新規ユーザー ID およびパスワードに変更します。
統合リポジトリーを VMM 構成から削除する このタスクは、デフォルトのファイル・ベース・リポジトリーを構成から削除します。
統合リポジトリーを使用した後、ユーザー・レジストリーを管理する必要があるかもしれません。以下の任意のオプション・タスクを実行して、スタンドアロン LDAP ユーザー・レジストリーを微調整できます。
表 26. 統合リポジトリーを管理するオプション・タスク
タスク 説明
統合 LDAP ユーザー・レジストリーを更新する このオプションを選択すると、バインド ID およびパスワードなどの特定のパラメーターを更新して、LDAP ユーザー・レジストリー関連の問題を修正します。
統合データベース・ユーザー・レジストリーを更新する このオプションを選択すると、データ・ソース名、データベース URL、およびデータベース・タイプなどの特定のパラメーターを更新して、データベース・ユーザー・レジストリー関連の問題を修正します。
新規レルムを作成する このオプションを選択すると、レルムを作成します。レルムとは、WebSphere Portal 内で一貫性のあるグループを形成する、1 つ以上のユーザー・レジストリーから抽出したユーザーのグループです。 レルムにより、さまざまな構成オプションでの、柔軟なユーザー管理を行うことができます。 レルムは、仮想ポータルにマップして、定義済みユーザーがその仮想ポータルにログインできるようにする必要があります。統合リポジトリーでは、複数のレルムを作成できます。
プロパティー拡張データベース (以前は索引データベースと呼ばれました) このオプションを選択すると、追加属性を LDAP ユーザー・レジストリーではなく、VMM プロパティー拡張内に保管します。 Common Mail ポートレットや IBM Lotus Web Content Management などのアプリケーションは、プロパティー拡張データベースを使用して追加属性を保管します。 プロパティー拡張データベースを使用可能にした後、属性を追加してユーザーのビジネス要件に合わせることができます。
エンティティー・タイプを作成する LDAP ユーザー・レジストリー内ではなく WebSphere Portal 内に存在するエンティティー・タイプを使用する場合は、このオプションを選択します。 このオプションは、ユーザー・レジストリー内でエンティティー・タイプを作成し、WebSphere Portal とユーザー・レジストリー間でエンティティー・タイプをマップする相対識別名 (RDN) を追加します。
既存のエンティティー・タイプを更新する このオプションを選択すると、既存の単一エンティティー・タイプのデフォルトの親を更新します。 例えば、あるリポジトリーを削除したものの、エンティティー・タイプがその削除されたリポジトリーを指している場合、情報を更新して新規リポジトリーを指すようにする必要があります。

Virtual Member Manager の統合

IBM WebSphere Application Server には、 IBM WebSphere Portal がユーザーおよびグループの情報にアクセスするために使用する Virtual Member Manager (VMM) が組み込まれています。 VMM は、WebSphere Portal と任意のリポジトリー (統合リポジトリー、スタンドアロン・リポジトリー、または独自のカスタム・ユーザー・レジストリーなど) との間の通信を使用可能にするインターフェースです。

Virtual Member Manager (VMM) は、WebSphere Application Server インフラストラクチャー内の抽象コンポーネントです。 下図に示すように、WebSphere Portal は、ポータル・ユーザー管理アーキテクチャー (PUMA) システム・プログラミング・インターフェース (SPI) を使用して、ユーザー・オブジェクトで属性を検索および設定します。PUMA は、これらの要求を VMM に渡します。次に VMM は、VMM をリポジトリーに接続する、対応するレジストリー・アダプターに要求を渡します。

WebSphere Portal と Virtual Member Manager との相互作用の図。この図について詳しくは、このトピックのテキストを参照してください。

前述の図には以下のコンポーネントが組み込まれています。
統合リポジトリー

複数のリポジトリーをサポートする、すぐに使用可能な UserRegistry インターフェースの実装。 統合リポジトリーと通信する場合、WebSphere Application ServerWebSphere Portal の両方がすべての操作を VMM にディスパッチします。

スタンドアロン LDAP

単一の LDAP ディレクトリーをリポジトリーにする、すぐに使用可能な UserRegistry インターフェースの実装。 WebSphere Application Server は、スタンドアロン LDAP と直接通信します。 WebSphere Portal は、VMM を介してスタンドアロン LDAP と通信します。

VMM SPI

VMM は、リポジトリーとの通信を使用可能にするサービス・プロバイダー・インターフェース (SPI) wim.Repository を提供します。 WebSphere Application Server は、この SPI を使用して統合リポジトリーに接続します。 WebSphere Portal は、この SPI を使用して、統合またはスタンドアロンなど、すべてのリポジトリーに接続します。

ユーザー・レジストリー・アダプター

VMM が特定のリポジトリー (LDAP ディレクトリー、データベース、ファイル、または他のリポジトリーなど) に接続することを可能にする VMM SPI の実装。 レジストリー・アダプターは、WebSphere Portal および任意のリポジトリーの間の通信を使用可能にします。

重要: カスタム・ユーザー・リポジトリーまたは WebSphere Portal がすぐにサポートできないリポジトリーの使用を予定している場合、ユーザー・レジストリー・アダプターを作成する必要があります。 ユーザー・レジストリー・アダプターを作成するには、wim.Repository インターフェースを実装します。 詳細および手順については、WebSphere Application Server インフォメーション・センター内の以下のトピックを参照してください。
  • Repository SPI (仮想メンバー・マネージャー・アダプター用のシステム・プログラミング・インターフェース)
  • フェデレーテッド・リポジトリーのサンプル・カスタム・アダプターの例

レルムのサポート

レルムとは、リポジトリー・ツリーの 1 つ以上のブランチから取得したユーザーまたはグループの集合です。 それらのブランチは、例えば LDAP ユーザー・レジストリーのような単一リポジトリーの一部であっても、複数のユーザー・レジストリーの組み合わせであってもかまいません。 レルムのユーザー集団が仮想ポータルにログインできるようにするには、その仮想ポータルにレルムをマップします。この機能により、WebSphere Portal 内で、制限されたユーザー集団のみがアクセスできる領域を定義できます。

例えば、アジア、ヨーロッパ、米国、およびカナダに従業員を持つ国際的な企業の場合、これらの従業員のサブセットにのみ適用されるアプリケーションや情報が存在することがあります。 従業員のあるサブセットを作成して、このレルム用のアプリケーションまたは情報が含まれた仮想ポータルを作成することができます。 あるレルムのユーザーが別のレルムにアクセスすることは、そのレルムのメンバーでない限りできません。 例えば、wpsadmin ユーザーが 仮想ポータルにログインすることは、wpsadmin ユーザーが対応するレルムのメンバーでない限りできません。

さまざまなユーザー・レジストリーからのユーザーを結合するレルムを作成できます。例えば、レルムは 3 つの LDAP ユーザー・レジストリーと 1 つのデータベース・ユーザー・レジストリー (LDAP1、LDAP2、LDAP3、および DB1) にわたって作成できます。
要確認: 複数のユーザー・レジストリーを結合する前に、レジストリーで以下の制限事項を確認し、問題があれば訂正してください。
  • レルムにおける識別名は、すべてのレジストリーで固有でなければなりません。例えば、uid=wpsadmin,o=yourco が LDAP1 内に存在する場合は、このユーザーが LDAP2、LDAP3、または DB1 内に存在することはできません。
  • レルムにおける短縮名 (例えば wpsadmin) は、すべてのレジストリーで固有でなければなりません。
  • レルム内で使用されるすべてのレジストリーの基本識別名は重複してはなりません。例えば、LDAP1 が c=us,o=yourco の場合、LDAP2 を o=yourco にしてはなりません。
  • レルム内で使用されるどのレジストリーでも、基本エントリーを空白にしてはなりません。
  • IBM Lotus Domino が複数のレジストリー構成内のユーザー・レジストリーの 1 つになり、別のユーザー・レジストリーとレルムを共有する場合には、グループが必ず、デフォルトのフラット・ネーミング構造ではなく階層フォーマットで Domino Directory に保管されるようにしてください。 例えば、フラット・ネーミング規則は cn=groupName ですが、 階層フォーマットは cn=groupName,o=root です。
  • このユーザーは、プロパティー拡張構成内ではなく、特定のユーザー・レジストリー内に存在している必要があります。 存在していない場合、このユーザーは、レルムのメンバーになることができません。

プロパティー拡張

以前に索引データベースとして知られていたプロパティー拡張により、バックエンド・ユーザー・レジストリーに影響を与えないで、追加のユーザー属性をデータベース・ストアに保管できます。LDAP が読み取り専用であるが、ユーザーが時間帯などの追加属性を指定できるという要件がある場合には、プロパティー拡張を使用できます。 この追加属性はデータベース・ストアに保管できます。 また、リポジトリー・スキーマを変更できない場合には、アプリケーションの追加属性を追加することもできます。 プロパティー拡張は、統合リポジトリー、スタンドアロン LDAP ユーザー・レジストリー、またはカスタム・ユーザー・レジストリーで使用できます。

IBM Lotus Web Content Management は、以下の機能についての追加情報を格納しています。
  • Web コンテンツ・ユーザー・プロファイル
  • カテゴリー選択ツリー
この情報をメイン・リポジトリーに格納できない場合 (例えば、メイン・リポジトリーが読み取り専用の場合) は、プロパティー拡張構成が必要です。

クラスターに関する考慮事項

容量および可用性を増大させるために、IBM WebSphere Application Server Network Deployment を使用して、複数のポータル・サーバーをクラスター化できます。 クラスターでは、ポータルは共通の構成を共有し、また負荷がすべてのクラスター・インスタンスに均等に配分されます。

IBM WebSphere Portal は、一連のサーバーを中央で管理しクラスター化するためのデプロイメント・マネージャー・サーバー・タイプを提供する、IBM WebSphere Application Server 配布の WebSphere Application Server Network Deployment に標準装備されています。 一連のポータル・サーバーをクラスター化するとは、すべてのポータル・インスタンスが、同じ構成 (データベース、アプリケーション、ポートレットを含む) およびサイト設計を共有するということを意味します。 クラスターが提供するドメインで、大半の管理アクションが 1 回実行され、クラスター内の各サーバーと同期されます。 これにより、管理が単純化されると共に、すべてのクラスター・メンバーの構成および振る舞いが確実に等しくなります。

サーバー・クラスターはまた、セッションおよびキャッシュ・データを複製し、クラスターのすべてのメンバー間で整合性を保たせることのできる共有ドメインを提供します。 またクラスターは、アプリケーション同期機構も提供します。これは、クラスター全体でのアプリケーション管理 (開始、停止、更新など) の整合性を確保します。

WebSphere Application Server は、HTTP サーバー・プラグインを提供します。これにより、クラスターのすべてのメンバー間のユーザー・トラフィックのバランスを取ることができますし、また「セッション・アフィニティー」という機能により、セッション中、特定のクラスター・インスタンスにユーザーをバウンドしたままにすることで効率とパフォーマンスを改善できます。 さらに、クラスター・メンバーがダウンした場合、プラグインのワークロード管理機能は、インスタンスが使用できなくなったことを認識し、代わりのトラフィックの経路を指定します。

クラスターには、垂直クラスターと水平クラスターの 2 つのタイプがあります。 ほとんどの大規模デプロイメントでは、両方のクラスター・タイプを混合して使用します。

また、複数のポータル・クラスターをデプロイして、可用性、フェイルオーバー、および災害復旧を向上させることもできます。

クラスターのセットアップに関係する詳しい情報を、クラスターのガイドラインおよび制限事項のトピックで検討することをお勧めします。

クラスターのセットアップに関するガイドライン

WebSphere Portal クラスターのセットアップを計画するときは、WebSphere Application Server ノードに必要なクラスター計画について考慮する必要があります。 WebSphere Application Server のクラスター化に精通していない場合は、着手するのに役立つリソースがここにあります。

始める前に

WebSphere Application Server では、クラスターはアプリケーション・サーバーの複数の同じコピーで構成されます。 クラスター・メンバーは、クラスター内の単一のアプリケーション・サーバーです。WebSphere Portal は 、WebSphere Application Server インフラストラクチャーにおけるエンタープライズ・アプリケーション・サーバーとして インストールされます。WebSphere Application Server インフラストラクチャーで使用可能なクラスター機構はすべて、WebSphere Portal でも 使用可能であり、適用されます。したがって、WebSphere Portal クラスターは、同じように構成された 複数の WebSphere Portal サーバーの単なる集合です。

計画に関する追加情報については、 http://www.ibm.com/software/ webservers/appserv/was/library/ で該当する IBM WebSphere Application Server Network Deployment バージョンを参照してください。

クラスター環境を実装するためのガイドライン
クラスター環境は、以下のガイドラインに従って実装する必要があります。
  • 32 ビットおよび 64 ビットの混合オペレーティング・システム環境を構築できます。例えば、デプロイメント・マネージャーを 64 ビットのオペレーティング・システムにインストールし、ポータル・ノードを 32 ビットのオペレーティング・システムにインストールすることができます。
  • クラスター環境で外部の Web サーバーを構成するために使用できるいくつかのアプローチがあります。 WebSphere Portal をインストールするためにここに提供された説明は、WebSphere Application Server によって推奨されたアプローチに従っています。 この方法では、セルがセットアップされた後にバイナリーのプラグイン・モジュールをインストールするためにプラグイン・インストール・ウィザードを使用します。 クラスター環境で外部の Web サーバーを構成する場合の推奨される手順の詳しい説明については、以下の情報を参照してください。
  • デプロイメント・マネージャー・ノードは必ず、 セルとクラスターを構成する前に、別途インストールします。
  • WebSphere Application Server は、クラスター環境における HTTP セッション・フェイルオーバーの技法として、データベース・セッション・パーシスタンスおよびメモリー間複製を提供しています。 以下の情報を検討して、クラスターにおいてこれらの技法のいずれかを使用するかどうか決定します。
  • IBM WebSphere Virtual Enterprise 動的クラスターを作成して、WebSphere Portal を実行できます。動的クラスターの一部になるノードごとに、WebSphere Virtual Enterprise デプロイメント・マネージャーを使用したクラスターのセットアップの説明に従ってください。
    IBM i の場合にのみ重要: WebSphere Virtual Enterprisei でのインストールをサポートしないため、動的クラスターはサポートされません。
  • wkplc.properties ファイルにある WasRemoteHostName および WasSoapPort プロパティーは、多数の ConfigEngine スクリプトがそれらに依存しているため、常に正確でなければなりません。 スタンドアロン環境の場合、これらのパラメーターは WebSphere_Portal アプリケーション・サーバーのホスト名および SOAP ポートを指している必要があります。 クラスター環境の場合、これらのパラメーターは Deployment マネージャーのホスト名および SOAP ポートを指している必要があります。 インストール時に指示された場合にのみ、これらのプロパティーを変更します。
  • セルにノードを追加した場合、またはデプロイメント・マネージャーにノードを統合した後でノードの構成を変更した 場合は、ノードの構成を同期化します。
  • 外部セキュリティー・マネージャーを、クラスター環境で認証または許可するように構成する場合は、まず、WebSphere Portal クラスターをインストールして構成します。 クラスターが正常に機能していることを確認してから、 外部セキュリティー・マネージャーの構成に進んでください。
  • i:: 次のコマンドを実行して、WebSphere Portal データベースのリサイクル手順をセットアップします。この手順により、未使用のジャーナル・ファイルが自動的に除去されます。
    CHGJRN JRN(Your DB2 DB Name/QSQJRN) DLTRCV(*YES)

    Your DB2 DB Namerelease.DbName プロパティー (wkplc_dbdomain.properties ファイル内にある) の値です。

クラスターのセットアップに関する制限

WebSphere Portal クラスターのセットアップの際には、以下の制限が適用されます。

  • クラスターを作成する前に、WebSphere Portal をスタンドアロン・ノードとしてインストールする必要があります。WebSphere Portal を管理対象ノードにインストールすることはできなくなりました。
  • クラスターの 初期セットアップ中の一時的な状態を除き、WebSphere Portal は、 クラスター環境に含まれていない管理対象ノードで実行する場合にはサポートされません。
    注: WebSphere Portal サーバーを 1 つだけ含むクラスターが作成されることがあります。その場合は、管理対象セルで単一の WebSphere Portal サーバーが作動可能になります。
  • クラスター環境では、グローバル設定ポートレットまたは XML 構成インターフェースを介して設定を変更することはできません。 WebSphere Application Server 管理コンソールでそれぞれのプロパティーを変更して、これらの変更を行わなければなりません。
  • クラスター環境での検索をサポートするには、クラスターに含まれていないアプリケーション・サーバーのノード上で、 リモート検索サービス用の検索をインストールおよび構成する必要があります。
  • WebSphere Portal の管理アクションは、そのアクションを実行したユーザーに即時に表示されます。 しかし、他のユーザーがその変更内容を確実に表示するためには、WebSphere Portal からいったんログアウトして再度ログインしなければなりません。 この制限は、クラスター環境と非クラスター環境の両方に適用されます。
  • クラスターまたはクラスター・メンバーを作成する場合は、 クラスター名やクラスター・メンバー名にスペースを使用しないでください。
  • IBM i の制限事項: 混合ノード環境へのインストールは、i 環境ではサポートされていません。
  • デプロイメント・マネージャーおよびクラスター内の各 WebSphere Portal ノードについて、各システム・クロック設定の差が互いに 5 分以内に収まっていることを確認してください。そうでない場合は、addNode コマンドは失敗します。

HTTP セッション・フェイルオーバー

クラスター環境では、特定のセッションのすべての要求は、クラスター内の同じサーバー・インスタンスへ送られます。すなわち、ユーザーは、セッションを確立すると (例えば、ログインすることで)、セッションの期間中は同じサーバー・インスタンスからサービスを提供されます。 セッションのユーザー要求を処理しているサーバーを確認するために、グローバル設定ポートレットを表示できます。 このポートレットに、要求を処理しているサーバーのノード名が表示されます。クラスター内のいずれかのサーバーに障害が起こると、 要求はクラスター内の別のサーバーに転送されます。 分散セッション・サポートが (持続セッションまたはメモリー間セッション複製のいずれかによって) 使用可能になっている場合、新規サーバーはデータベースまたは別のサーバー・インスタンスからセッション・データにアクセスできます。

分散セッション・サポートは、WebSphere Application Server 内で個別に構成する必要があります。 詳しくは、WebSphere Application Server の資料を参照してください。

デフォルトでは、フェイルオーバー・サポートは、WebSphere Portal および製品と一緒にインストールされているすべてのポートレットで使用可能です。 独自に開発したポートレットでフェイルオーバー・サポートを利用するには、ポートレットがベスト・プラクティスに従って実装されていることを確認する必要があります。

フェイルオーバーおよびデータ脱落

JVM メモリー内に保管されていて、アプリケーション・サーバーまたは WebSphere Portal サーバーによって複製が管理されていないデータは、フェイルオーバー時に失われる場合があります。 分散セッション・サポートを利用しても、障害時には、セッションまたは他の複製されたデータ域 (分散マップまたはレンダリング・パラメーターなど) に保管されていないアンコミット情報をリカバリーできません。 このような場合、ユーザーは、フェイルオーバーが発生した後で、 トランザクションを再始動しなければならない場合があります。 例えば、フェイルオーバーが発生したときに、 ポートレットでの作業中で、いくつかの異なる画面の間で移動していた場合は、 最初の画面に戻され、その画面で、これまでに行ったステップを繰り返す必要がある場合があります。 同様に、フェイルオーバーが発生したときにポートレットをデプロイしていた場合は、 そのデプロイメントは成功しない可能性があり、 その場合には、ポートレットを再デプロイする必要があります。 分散セッション・サポートが使用可能である場合は、 ノードに障害が発生しても、 ユーザー・ログイン・セッションの妥当性は維持されます。

ポートレットがフェイルオーバーをサポートしていない場合、 フェイルオーバーが発生すると、そのポートレットに関して、「ポートレットが使用不可です」というメッセージが表示されます。 ポートレットがフェイルオーバーを部分的または不完全にサポートしている場合、 フェイルオーバー前にポートレットによって表示されていたデータの一部は、 フェイルオーバーの発生後に表示されなくなるか、 またはポートレットが正しく作動しなくなる可能性があります。 そのような極端な場合には、ユーザーは、正常な操作を再開するため、 ログアウトしてから、再びログインする必要があります。

フェイルオーバーが発生すると、 要求は Web サーバー・プラグインによって別のクラスター・メンバーにリダイレクトされます。 たいていのブラウザーは、POST 要求をサブミットした後に、 リダイレクトに対する応答として GET 要求を発行します。 これにより、ブラウザーでは、ユーザーの知らない間に、 同じデータが複数回送信されることはありません。 ただし、フェイルオーバーの後に、 ユーザーはブラウザー内のページを最新表示するか、 または、戻ってフォームを再サブミットして POST データをリカバリーする必要があります。

注: POST データを使用するすべてのポートレットまたはアプリケーションが、この動作によって影響を受けます。
Web コンテンツ・オーサリング・ポートレットのフェイルオーバーに関する考慮事項

WebSphere Application Server での分散セッション・サポートを構成する場合には、持続セッションまたはメモリー間セッション複製のいずれの場合にも、 Custom tuning parameters 設定を構成して、複製されるセッション属性、および複製タスクの実行頻度を決定できます。 調整レベルは、パフォーマンスを最適化する「非常に高い」からフェイルオーバーを最適化する「低」まで設定できます。

Web コンテンツ・オーサリング・ポートレット使用時のフェイルオーバー後にセッション情報が保持されるようにするには、すべてのセッション属性が書き込まれるようにカスタム調整レベルを設定する必要があります。

例えば、書き込み頻度が 10 秒ごとの「時間に基づく」に設定されている場合、フェイルオーバーの 10 秒間に発生した Web コンテンツ・オーサリング・ポートレットのセッションに対するすべての変更は失われます。 書き込み頻度が「サーブレット・サービス終了時 (End of the servlet service)」に設定されている場合、Web コンテンツ・オーサリング・ポートレットのセッションはフェイルオーバー後にも損なわれません。

フェイルオーバー状態の間、Web Content Management ユーザーは、初期ナビゲーション画面に戻るか、ブラウザー・ウィンドウをリフレッシュする必要があります。 セッションまたは他の複製データ域に保管されていない、コミットされていないデータは失われます。 しかし、これら以外に失われるサービスはないはずなので、ユーザーは処理を続行できるはずです。

クラスター内のi データベースのセットアップ

データベースと通信するには、IBM i を実行しているサーバーは 2 つの JDBC ドライバー、IBM Toolbox for Java JDBC ドライバーまたは IBM Developer Kit for Java JDBC ドライバー (また、ネイティブ JDBC ドライバーとも呼ばれます) のどちらかを使用できます。 どちらの JDBC ドライバーを使用するかは、ご使用のクラスター環境をどのようにセットアップしているかによります。

JDBC ドライバーは、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc_dbtype.properties ファイル内の db2_iseries.DbDriver プロパティーで指定します。 手動でファイルを編集するか、または構成ウィザードを使用して適切な値を選択することにより、値を指定できます。
  • ネイティブ JDBC ドライバー: com.ibm.db2.jdbc.app.DB2Driver
  • IBM Toolbox for Java JDBC ドライバー: com.ibm.as400.access.AS400JDBCDriver
スケーリング・トポロジーの考慮事項
i環境での垂直および水平スケーリング・トポロジーは、データベースをデプロイする方法に従って異なる JDBC ドライバー構成を必要とします。
スケーリング・トポロジー JDBC ドライバーの考慮事項
垂直スケーリング 垂直クラスターをセットアップするとき、データベースをポータルと同じマシンにローカルにインストールするか、別のマシンにリモートでインストールできます。 データベースがインストールされる場所に応じて、適切な JDBC ドライバーを使用します。
  • ローカル・データベース: ネイティブ JDBC ドライバーまたは IBM Toolbox for Java JDBC ドライバーのいずれかを使用できます。
  • リモート・データベース: IBM Toolbox for Java JDBC ドライバーを リモート・データベースへの接続に使用する必要があります。
水平スケーリング 水平クラスターをセットアップする際に、IBM Toolbox for Java JDBC ドライバーを使用する必要があります。 クラスターに 1 次ノードおよび 2 次ノードのリモート・データベースを使用するのが標準的な構成です。 選択する場合、1 次ノードにローカル・データベースを使用して、他のリ モート・データベースの場合と同様に、2 次ノードを構成してデータベースを使用することがで きます。 ただし、ユーザー環境にローカル・データベースの組み込みを選択するかどうかにかかわらず、水平クラスターで IBM Toolbox for Java JDBC ドライバーを使用する必要があります。
i 水平クラスターでのローカル・データベースの使用
水平クラスターのセットアップの説明で、1 次ノードおよび 2 次 ノードの両方にリモート・データベースを使用する方法が述べられていますが、そ の代わりに 1 次ノードのローカル・データベースを使用するために、i水平クラスターを構成するように選択できます。
水平クラスターにおける 1 次ノードのローカル・データベースの構成。この例では、データベースおよび Web サーバーは、IBM® WebSphere® Portal および IBM WebSphere Application Server がインストールされているシステム (システム 1) にローカルにインストールされます。
システム 1 は 1 次ノードです。
システム 2 は 2 次ノードです。
注: 1 次ノー ドの代わりに 2 次ノードでローカル・データベースを使用することは可能ですが、この構成はテストされていないため、文書化されていません。
重要: このシナリオでは、1 次ノードにローカル・データベースを使用していますが、データベースがリモートであるかのようにすべてのデータベース接続が構成されます。 特に、1 次ノードおよび 2 次ノードの両方にデータベースを構成するとき、IBM Toolbox for Java JDBC ドライバー (com.ibm.as400.access.AS400JDBCDriver) を使用する必要があります。
1 次ノードにローカル・データベースを使用するには、wp_profile_root/ConfigEngine ディレクトリーのプロパティー・ファイルを更新するときに以下のバリエーションを用いて、データベース構成を実行します。
wkplc_dbtype.properties
  • db2_iseries.DbDriver プロパティーに JDBC ドライバーを指定する。 例:
    db2_iseries.DbDriver=com.ibm.as400.access.AS400JDBCDriver
  • db2_iseries.DbDriverType プロパティーにリモートとしてデータベース・ロケーションを指定する。 例:
    db2_iseries.DbDriverType=4
wkplc_comp.properties
  • domain.DbName プロパティーに 1 次ノードのホスト名を指定する。 例: release.DbName=primary_host_name/wpsdb
  • domain.DbUrl プロパティーに 1 次ノードのホスト名を指定する。 例: release.DbUrl=jdbc:as400:primary_host_name/wpsdb
注: データベース転送に構成ウィザードを使用する場合、プロパティー・ファイルではなくウィザード・パネルの値を更新する。

説明されているように他のすべての構成を完了する。 このシナリオで 2 次ノードを構成するとき、データベース転送に 1 次ノードのホスト名を使用して、リモート・データベースと同様にデータベース構成を実行します。

セキュリティー・オプション

IBM WebSphere Application Server および IBM WebSphere Portal のセキュリティー・モデルは、クラスターでのセキュリティーの計画およびインプリメンテーションに影響を与えます。 WebSphere Application Server デプロイメント・マネージャーでは、デフォルトでセキュリティーが有効になっています。ノードが統合されている場合、WebSphere Portal はデプロイメント・マネージャー・セルでセキュリティー設定を変更しようとしません。 これは、スタンドアロンの WebSphere Portal がデプロイメント・マネージャー・セルを結合すると、既存のセキュリティー構成がそのセルのセキュリティー設定に置き換えられることを意味します。 デプロイメント・マネージャー・セルからノードを除去すると、元のセキュリティー設定が復元されます。

デフォルトのセキュリティー設定
デプロイメント・マネージャー・プロファイルおよび WebSphere Portal プロファイルのインストールで有効なデフォルト・セキュリティーは、単一のファイル・ベース・リポジトリーが構成されている Virtual Member Manager (VMM) 統合セキュリティーです。 スタンドアロン・ノードをデプロイメント・マネージャー・セルに追加する場合は、WebSphere Portal ノードの目的がデプロイメント・マネージャー・セルを結合し、クラスターの一部として実行することである場合、このノード上でデフォルト・セキュリティー設定を変更する必要はありません。 統合中、スタンドアロン環境のセキュリティー設定が、デプロイメント・マネージャーのセキュリティー設定に置き換えられます。 元のスタンドアロン環境のセキュリティー設定は保存され、そのノードがクラスターから除去された場合に元の設定に戻されます。
注: 管理セキュリティーがデプロイメント・マネージャーのインストール中に選択解除された場合、またはデプロイメント・マネージャーのインストール後に使用不可になった場合には、WebSphere Portal クラスター・メンバー上でセキュリティー構成タスクを実行する前に、それを使用可能にする必要があります。
クラスターのセキュリティー・オプション

クラスターで使用できる多数のセキュリティー・オプションがあります。 すべての VMM 統合セキュリティー・オプション (複数の LDAP リポジトリー、データベース・リポジトリー、およびデフォルト・ファイル・ベース・リポジトリーを含む) を使用できます。 さらに、VMM 統合セキュリティーのアプローチではなくスタンドアロン LDAP セキュリティーを使用するためのオプションもあります。

WebSphere Portal は、多数のセキュリティー・タスクを提供しており、これを使用して、WebSphere Application Server のセキュリティー設定の変更と WebSphere Portal 構成に対する必要な更新をシングル・ステップで実行できます。 WebSphere Portal ノードがデプロイメント・マネージャーのセルに統合されるとすぐに、実行されているすべての WebSphere Portal セキュリティー・タスクにより、デプロイメント・マネージャーのセル上のセキュリティー構成が更新されます。 デプロイメント・マネージャーのセルにはセキュリティー・タスクの実行に必要な構成リソースが含まれていないため、セキュリティー・タスクは WebSphere Portal ノードの統合後に実行してください。

「クラスター実稼働環境のセットアップ (Setting up a clustered production environment)」にあるタスクは、追加ノードを構成する前に、セキュリティーを構成することを推奨します。 追加ノードの構成後にセキュリティーを構成する場合、またはクラスター環境の作成後にセキュリティー構成を更新する必要がある場合には、2 次ノード上のセキュリティー構成を更新する追加タスクを実行する必要があります。詳しくは、「クラスター作成後のセキュリティーの構成 (Configuring security after cluster creation)」を参照してください。

注: 実稼働環境においてファイル・ベース・リポジトリーを使用することは推奨されていません。 なぜなら、更新は WebSphere Application Server 管理コンソールによってのみ可能で、ポータル・ユーザー管理からは行えないからです。 これらの更新は、デプロイメント・マネージャーのファイル同期を使用してセルの各ノードに送られます。 このことは、ユーザーおよびグループが大量の場合、時間がかかる可能性があります。 また、セルのすべてのノードで同期が同時に行われることはないため、セルのノードが異なるセキュリティー定義を持つ時間枠が発生します。

セキュリティー・シナリオ

クラスターをセットアップする場合、考慮しなければならない 2 つのシナリオがあります。 1 つ目のシナリオは、デプロイメント・マネージャーがセキュリティー設定を構成していないクラスター環境を最初にセットアップする場合で、すぐに使用できるセキュリティーがあります。 2 つ目のシナリオは、ノードをセルと結合する前に、既存のデプロイメント・マネージャーが既にセキュリティー設定を構成している場合です。

すぐに使用できるセキュリティー

最初のシナリオは、デフォルトの Virtual Member Manager (VMM) ファイル・ベース・リポジトリー・セキュリティーが WebSphere Portal ノードとデプロイメント・マネージャーの両方で使用される場合です。 WebSphere Portal ノードがデプロイメント・マネージャー・セルに統合されるとき、ノードのセキュリティー設定が、デプロイメント・マネージャーのセキュリティー設定に置き換えられます。 したがって、最初の WebSphere Portal ノードをセルに統合する前に、WebSphere Portal アドミニストレーターおよび管理ユーザー (例えば wpsadmins や wpsadmin) の必要なグループがデプロイメント・マネージャーのセキュリティー・リポジトリーで定義されている必要があります。 そうしなければ、ノードをデプロイメント・マネージャーに統合する際に、WebSphere Portal アドミニストレーター・グループおよび管理ユーザーが失われます。

クラスターがセットアップされれば、セルのセキュリティー設定を変更できます。 IBM WebSphere Application Server 管理コンソールを使用してセルのセキュリティーを変更することは可能ですが、WebSphere Application Server および WebSphere Portal のセキュリティー構成設定が全く同一になるようにするため、WebSphere Portal セキュリティー・タスクを使用してセルのセキュリティーを変更する必要があります。
注: WebSphere Application Server 管理コンソールを使用した、すぐに使用可能なセキュリティーの構成または更新は、スタンドアロン環境ではサポートされません。 これがサポートされるのは、デプロイメント・マネージャーの管理コンソールを使用するクラスター環境のみです。
Virtual Member Manager (VMM) が統合される場合のセキュリティーの変更

2 番目のシナリオは、最初の WebSphere Portal ノードとセルを結合する前に、既存のデプロイメント・マネージャー・セルがすでにデフォルト・セキュリティー設定を変更している場合です。 WebSphere Portal では、 WebSphere Portal ノードのセルへの統合時に 2 つの管理ユーザー ID とパスワードのクリデンシャルのセット (WebSphere Portal ノードの認証用のセット、 およびデプロイメント・マネージャーの認証用のセット) を使用する機能がサポートされています。 これは、WebSphere Portal がセルを結合する前に、共通する管理ユーザー ID を定義する必要がないことを意味します。デプロイメント・マネージャー・セルが統合 VMM を追加リポジトリーと共に使用する場合、Portal ノードでのセキュリティー設定は、デプロイメント・マネージャーの変更された VMM 統合セキュリティー設定に置換されます。 元のスタンドアロン環境のセキュリティー設定は保存され、そのノードがクラスターから除去された場合に元の設定に戻されます。

スタンドアロン Lightweight Directory Access Protocol (LDAP) サーバーでのセキュリティーの変更

デプロイメント・マネージャー・セルがスタンドアロン LDAP セキュリティーを使用する場合は、統合の前に WebSphere Portal プロパティー・ファイルで LDAP 値を構成する必要があります。 このようにして、WebSphere Portal が、セルの既存のスタンドアロン LDAP セキュリティーの設定に動的に適合できるようにします。 最初のシナリオの場合と同様に、クラスターがセットアップされれば、デプロイメント・マネージャー・セルのセキュリティー設定に対するセキュリティーの変更は、WebSphere Portal セキュリティー・タスクを使用して行うことができます。また、同じ手順に従って、追加の WebSphere Portal ノードがセルに追加される場合もあります。

クラスターでの外部セキュリティー・マネージャーの使用

外部セキュリティー・マネージャーを使用して IBM WebSphere Portal のセキュリティーを構成する場合は、使用する外部セキュリティー・マネージャーに応じて、いくつかの追加の考慮事項を検討してください。 外部セキュリティー・マネージャーの構成は、他のすべてのセットアップ (WebSphere Portal クラスターが機能することの確認を含む) が完了した後に実行します。 さらに、「システム要件」ファイルを検討して、外部セキュリティー・マネージャー・ソフトウェアのサポートされるレベルを使用していることを確認してください。

一般的な考慮事項

以下の考慮事項は、すべての外部セキュリティー・マネージャーに適用されます。

  • クラスターで外部セキュリティー・マネージャーを使用するようにセキュリティーをセットアップする場合は、以下のトピックの説明に従い、クラスター内の各ノードのセキュリティー構成を確認し、必要であれば構成を行う。
  • 外部セキュリティー・マネージャー構成を最初にセットアップした後で、その構成に何らかの変更を行った場合、まず最初に、クラスターの 1 次ノード上で wkplc_comp.propreties の変更を行う。 クラスターに追加ノードが存在する場合は、1 次ノード上の wkplc_comp.properties ファイルに行った変更がすべて、クラスター内の他のノード上の wkplc_comp.properties ファイルに伝搬されていることを確認します。
Tivoli Access Manager クラスターに関する考慮事項
  • クラスター内の各ノード上で validate-pdadmin-connection タスクを実行する。
  • validate-pdadmin-connection タスクが失敗した場合は、 validate-pdadmin-connection を再度実行する前に、 run-svrssl-config タスクを実行する。 run-svrssl-config タスクを実行する前に、wkplc_comp.properties ファイル内の wp.acc.impl.PDServerName パラメーターが Tivoli Access Manager への個々の構成済み AMJRTE 接続を表し、 クラスター内の各ノードが wp.acc.impl.PDServerName に対して固有な値を有していなければならないことに注意してください。
  • 外部 Web サーバーを使用している場合は、WebSphere Portal クラスターで外部セキュリティー・マネージャーを構成するタスクを実行する前に、 追加の構成が必要になる。 各ノード上でファイル wkplc_comp.properties を編集し、 プロパティー wp.ac.impl.JunctionHost および wp.ac.impl.JunctionPort の値を Web サーバーに使用するバックエンド・サーバーのホスト名およびポート番号に確実に設定します。
  • クラスター内の各ノード上で、wkplc_comp.properties ファイルにある WebSEAL Trust Association Interceptor (TAI) パラメーターが同じであることを確認する。 WebSEAL ジャンクションを上書きする構成タスクを後で実行する場合、WebSphere Application Server TAI プロパティーは自動的には更新されないため、 手動ですべてのノードが同じパラメーターを使用するようにする必要があります。 ノードが同じであることを手動で確認するには、デプロイメント・マネージャーの管理コンソールを使用して、「セキュリティー」 > 「グローバル・セキュリティー」 > 「Web および SIP セキュリティー」 > 「トラスト・アソシエーション」 > 「インターセプター」 > 「com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus」 > 「カスタム・プロパティー」にナビゲートします。
  • wkplc_comp.properties ファイル内の wp.ac.impl.PDPermPath パラメーターで指定されたファイルの場所に入力する。このプロパティーは、Tivoli Access Manager AMJRTE プロパティー・ファイル (PdPerm.properties) の場所を示します。 各種のオペレーティング・システムのノードで構成されているクラスターでは、 PdPerm.properties ファイルの場所は、ノードごとに異なる場合があります。

    この値は、com.ibm.websphere.security.webseal.configURL プロパティーを使用して、 すべてのクラスター・メンバーに対してグローバルに設定できます。このプロパティーにアクセスするには、デプロイメント・マネージャーの管理コンソールで、「セキュリティー」 > 「グローバル・セキュリティー」 > 「Web および SIP セキュリティー」 > 「トラスト・アソシエーション」 > 「インターセプター」 > 「com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus」 > 「カスタム・プロパティー」をクリックします。 デプロイメント・マネージャーのセキュリティー構成は、各ノードのファイル・システム・タイプに関係なく作動するため、configURL プロパティーの値は、管理コンソールでの指定に従って各ノード上で解決する必要があります。

    PdPerm.properties ファイルの場所が正しく指定されたことを確認するには、 以下のアプローチのいずれかを使用します。
    • ノードがすべて UNIX プラットフォーム上にある場合は、UNIX リンク・コマンド (ln) を使用して、0.om.ibm.websphere.security.webseal.configURL の値が各ノード上で解決されることを確認する。
    • PdPerm.properties ファイルの場所がノードごとに異なり、ご使用のクラスターが異なるプラットフォームで構成される場合、 このプロパティーは WebSphere Application Server 変数を受け入れて、ファイルを正しく参照するよう各ノードのファイル・システム上の場所を設定できます。
eTrust SiteMinder クラスターに関する考慮事項

クラスター内の各ノード上に eTrust SiteMinder バイナリーをインストールして検証したことを確認します。

認証に eTrust SiteMinder だけを使用している場合は、Application Server Agent をインストールして検証します。

認証および許可に eTrust SiteMinder を使用している場合は、Application Server Agent および SDK の両方をインストールして検証する必要があります。

複数のクラスターに関する計画

複数のクラスターのセットアップに関連した概念の概要を理解します。 複数クラスターは、セルと呼ばれる単一の管理ドメイン内で共に管理され、ワークロード管理に参加するサーバーの集合です。

IBM WebSphere Application Server Network Deployment は、単一の管理ドメイン、つまりセル内で多数のアプリケーション・サーバーと アプリケーション・サーバー・クラスターを管理する機能を備えています。 単一のセルには、以下の利点があります。
  • 単一の管理ユーザー・インターフェース (管理コンソール)
  • 単一の管理スクリプト・クライアント (wsadmin)
  • セル、ノード、またはサーバー・スコープでの共用リソース
  • アプリケーション・データ、状態情報、およびキャッシュを共用するための複製ドメイン
  • Web サーバー・レベルでのワークロード管理。これにより、セルでホストされるすべてのアプリケーションに対して 単一のサーバー ID が提供され、アプリケーション間で容易にコラボレーションを行うことが可能となり、 アプリケーションに対する優れたエンド・ユーザー・エクスペリエンスが実現されます。

管理者の目標は、同じ管理対象セル内で可能な限り多くの WebSphere Portal と ポータル・ベース製品を管理し、これらの管理機能とランタイム機能を活用することです。

WebSphere Portal は、別々に構成された複数のポータルを同一セル内に統合する機能を備えています。 このサポートには制限がありますが、 これにより、あるポータルが別のポータルと異なるアプリケーションまたはサービスを提供するような複数のクラスターを 共に管理できます。 Web サーバーを通じて共通のサーバー ID が提供されるので、これらのサービスとアプリケーションは、 Web 2.0 の最新テクノロジーを通じて (Ajax や REST サービスなどの使用を通じて)、ブラウザーでシームレスに統合できます。

単一セル内での複数のクラスターの動作
セルの構成にはスコープの概念があることを、最初に理解することが重要です。 スコープにより、その他のリソースとアプリケーション・サーバー・インスタンスに対するリソースの可視性が制御されます。 リソースの例としては、データ・ソース定義や WebSphere 変数定義などがあります。 通常、スコープは、以下のいずれかとして定義されます。
セル
このスコープで定義されるすべてのリソースは、セル内で定義されるその他のすべてのリソースに対して可視になります。 つまり、グローバルに使用できるように構成されます。
Node
セルには、1 つ以上のノードがあります。各ノードは、名前を持っており、ある物理的なサーバー上の 特定の WebSphere Application Server プロファイルに一致します。 このスコープで定義されるすべてのリソースは、この同じノードで定義されるその他のリソース (任意のサーバー定義を含む) に 対してのみ可視になります。
サーバー
ノードには、1 つ以上のサーバー定義があります。 このスコープで定義されるすべてのリソースは、そのサーバーに対してのみ可視になります。 その他のサーバーまたはノードは、これらのリソースを利用できません。
クラスター
クラスター・スコープで定義されるリソースは、このクラスター内のすべてのクラスター・メンバーまたはサーバー・インスタンスに対して 可視になりますが、同じノード内のその他のサーバーに対しては可視になりません。
上図ではスコープの概念を説明。
注: 上図の円の中に定義されているリソースは、その円の中で定義されているその他のすべてのリソース、およびその円の中で定義されているその他のすべてのスコープによって認識されます。
このスコープの概念で重要な点は、エンタープライズ・アプリケーションはすべてセル・スコープであることです。 つまり、特定の名前を持つエンタープライズ・アプリケーションは、セル内で 1 つしか存在できません。 複数のサーバーおよびクラスター、または複数のクラスターでそのエンタープライズ・アプリケーションを使用する必要がある場合は、 エンタープライズ・アプリケーションを共用する必要があります。
注: IBM WebSphere Virtual Enterprise は、同じエンタープライズ・アプリケーションの複数のエディションを 管理する機能を備えています (異なるサーバーおよびクラスター、または異なるクラスターに対するこれらのエディションのマッピングを含む)。ただし、WebSphere Portal はこの機能を現在は活用しません。

通常、複数のクラスター間で共用するエンタープライズ・アプリケーションをインストールする場合、 管理者は、セルの管理サーバーであるデプロイメント・マネージャーにエンタープライズ・アプリケーション・アーカイブ (EAR) を 単にインストールし、アプリケーションを実行先のターゲット・クラスターにマップします。 WebSphere Portal がその基本構成の一部としていくつかのエンタープライズ・アプリケーションを インストールしたら、通常は、どのクラスターを定義するよりも前に、特別な手順を実行する必要があります。この手順は、 同一セル内に複数の WebSphere Portal クラスターを定義したときに、 これらのインフラストラクチャー・アプリケーションが適切に共用されるようにするためのものです。 そして、これらはインフラストラクチャー・アプリケーションなので、 WebSphere Portal ベースのクラスターは、すべて同じバージョンでなければなりません。

ポートレットは、特殊なタイプのエンタープライズ・アプリケーションです。そのため、ポートレットを複数のクラスター間で共用することも可能ですが、それが必ずしも適切とは限りません。 多くのポートレット (例えば、WebSphere Portal 管理) は、インフラストラクチャーの一部であると 見なされるので、複数のクラスター間で共用することが可能です。 大部分のエンド・ユーザー・アプリケーション・ポートレットは、特定のクラスターに固有のものとなり、 そのようなものとしてインストールされます。 詳しくは、ポートレット・デプロイメントのベスト・プラクティスのセクションを参照してください。

また、セルの J2EE セキュリティー構成は、セル内で管理されるすべてのサーバーとクラスターにより共用されます。 したがって、ユーザーがその同じセル内のサーバー/クラスターでホストされるアプリケーションを使用するときは、 基盤となるユーザー・リポジトリーに対して認証されますが、それぞれのサーバーとクラスターは、 これと同じユーザー・リポジトリーを共用する必要があります。

簡単にまとめると、複数のクラスターを同一セル内でサポートするには、以下が必要です。
  • すべてのクラスターに共通のセキュリティー・モデル (ユーザー・リポジトリーを含む)
  • いくつかの共通のエンタープライズ・アプリケーションおよびポートレット。これらは、 統合およびクラスター・プロセスの一部として共通化する必要があります
  • 特定のクラスター、またはクラスター全体に、必要に応じてポートレットをインストールする
  • エンタープライズ・アプリケーションがクラスター間で共用されているかどうかを確認する方法を理解する
  • 使用目的に応じて、適切なスコープでその他のリソースを定義する
制限
ポータル・クラスターはすべて、同じ保守レベルでなければなりません
WebSphere Portal は、いくつかのエンタープライズ・アプリケーションから構成されています。 また、これらのアプリケーションは、基盤となるサービスおよびインフラストラクチャーと緊密に結合しています。 そのため、同一セル内のポータル・ベース・クラスターはすべて、同じサービス・レベルでなければなりません。
プロセス・サーバーの考慮事項
複数のクラスターが共通の WebSphere Process Server にアクセスする必要がある場合は、サーバーをその独自のクラスター内の中央に配置します。そして、WebSphere Process Server のクライアント・インストール・オプションを WebSphere Portal と共に使用して、中央のプロセス・サーバー・クラスターへのリモート・アクセスができるようにしてください。
WebSphere Virtual Enterprise 静的クラスター
WebSphere Virtual Enterprisei にはインストールできないため、WebSphere Virtual Enterprise はリモートの非 i マシンにインストールし、 WebSphere Virtual Enterprise On Demand Router (ODR) を使用して複数のクラスター間でワークロードのバランスを取る必要があります。 ODR については『クラスター全体への要求のルーティング』を参照してください。
複数のクラスター間で共用するデータベース

一般的な IBM WebSphere Portal 環境では、リリース・ドメイン、カスタマイズ・ドメイン、コミュニティー・ドメインなど、 複数のデータベース・ドメインが使用されます。 通常、これらのドメイン内のデータの関連度は、WebSphere Portal ごとに異なります。 つまり、アプリケーションの組み合わせとユーザー・コミュニティーはたいてい異なるため、 構成が異なれば、使用されるデータベース・ドメインも異なることになります。通常は、保守やフェイルオーバーを簡単にするために、データベース・ドメインの多くが共用されている可能性のある同一セル内で、全く同様に構成された複数の WebSphere Portal インストールをサポートするのがよいでしょう。

別々に構成された 2 つのクラスターが同一セル内に存在する場合は、 各クラスターごとに、専用のデータベース・ドメイン・セットが必要です。全く同様に構成された 2 つのクラスターが同一セル内に存在する場合は、リリースおよび JCR データベース・ドメインを除き、すべてのデータベース・インスタンスを共用する必要があります。 これにより、各クラスターの静的な構成を別々に更新できる状態でありながら、ユーザー固有のデータとコミュニティーのデータがすべてクラスター間で共用されるようになります。

ドメインを共用する場合の特殊なデータベース考慮事項
同じ IBM WebSphere Application Server セル内に複数のクラスターを構成する場合は、データベース設定に特に注意する必要があります。
  • 現在の構成状態に基づいて、どのデータベース・ドメインを同じセル内の他のクラスターと共用するかを決定します (複数クラスター環境)。
    重要: JCR ドメインおよびリリース・ドメインをさまざまな Web Content Management クラスターまたはサーバー間で共用することはできません。 Web Content Management システム内の異なるクラスターまたはサーバーごとに、別々の JCR またはリリース・ドメインを使用する必要があります。 例:
    表 27. すべてのクラスターまたはサーバー間で別々の JCR またはリリース・ドメインの例
    開発サーバー オーサリング・クラスター ステージング・サーバー 配信クラスター
    JCR ドメイン 1 JCR ドメイン 2 JCR ドメイン 3 JCR ドメイン 4
    リリース・ドメイン 1 リリース・ドメイン 2 リリース・ドメイン 3 リリース・ドメイン 4
  • どのデータベースをクラスター間で共用し、どれをクラスターごとに固有とするかに基づいて、ドメインのデータ・ソース名を割り当てます。 共用と非共用が混在する複数のドメインがある場合、それらのドメインに対して単一のデータ・ソースを使用することはできません。
  • 同じセル内のすべてのクラスター間でエンタープライズ・アプリケーションを共用する場合は、同じ名前を持つ同数のデータ・ソースを保守します。これにより、アプリケーションが稼働するすべてのクラスターで、アプリケーションのデータ・ソース・バインディングを解決できます。
  • 次のクラスター (クラスター B) の 1 次ノードをインストールするときに、共用データベース・ドメインを使用するようにノードを構成できます。このように構成するには、wkplc_dbdomain.properties および wkplc_dbtype.properties ファイルの該当するプロパティー値を設定します。

WebSphere Virtual Enterprise 動的クラスター

IBM WebSphere Virtual Enterprise 動的クラスターを作成して、IBM WebSphere Portal を実行できます。

IBM i の場合にのみ重要: WebSphere Virtual EnterpriseIBM i でのインストールをサポートしないため、動的クラスターはサポートされません。

動的クラスターの一部になるノードごとに、WebSphere Virtual Enterprise をデプロイメント・マネージャーとして使用する実稼働環境で WebSphere Portal をインストールおよび構成するための指示に従ってください。ただし、静的クラスターをセットアップするタスクは実行しないでください。すべてのノードをインストールおよび準備した後、WebSphere Portal 用の WebSphere Virtual Enterprise ノード・グループおよび動的クラスターをセットアップするために提供された指示に従ってください。

WebSphere Virtual Enterprise On Demand Router (ODR) コンポーネントでは、ワークロード・バランシング、優先順位付け、正常性モニター、および動的クラスターの動的操作などの機能を提供します。 ODR は、マルチクラスターのルーティング、リモート・セルにある動的クラスターの組み込み、および WebSphere Virtual Enterprise が実行されていないその他のサーバーへのルーティングを提供するように構成できます。 ODR は HTTP サーバー・プラグインの置き換えとして機能できますが、多くの構成ではその両方のコンポーネントが使用されます。 HTTP サーバーは DMZ (非武装地帯)に配置して、静的コンテンツをサービス提供し、ODR が常駐するプライベート・ネットワークへのエントリー・ポイントを提供できます。

WebSphere Portal クラスターにトラフィックを送付するためにオンデマンド・ルーター (ODR) を構成する場合は、あらかじめ以下の考慮事項を検討してください。
  • 内部ユーザーは、フロントエンド Web サーバーを経由しないで、直接 ODR に要求を送信できる。直接要求を送信する場合、HTTP 要求に via ヘッダーを追加するように ODR を構成する必要があります。 ODR カスタム・プロパティー http.compliance.via の値を true に設定します。詳しくは、下の「オンデマンド・ルーターの設定」リンクを参照してください。
    注: このステップは、Web サーバーを介して ODR にユーザー・トラフィックを送信する場合には必要ありません。その理由は、Web サーバーが HTTP 要求に via ヘッダーを付加するためです。
  • ODR は、入力 URL に基づいて、選択的にクラスターにトラフィックを送付できます。ODR に IP 別名の値を構成してからルーティング規則を定義し、各 IP 別名へのユーザー・トラフィックと適切な WebSphere Portal クラスターとを関連付けます。
  • ODR を使用して、同等のポータル・クラスター間で、トラフィックのロード・バランスを取ることができます。ODR の Multicluster Routing Policy (MCRP) を構成して、宛先クラスターおよびロード・バランシングのタイプを識別できます。詳細については、『マルチクラスターのフェイルオーバー用のオンデマンド・ルーターの構成とルーティングのロード・バランシング』を参照してください。
    注: ODR で、汎用サーバー・クラスター定義を使用してトラフィックをリモート・ポータルの静的クラスターに送付するよう構成する場合、MCRP ポリシーで使用する cell_name の値を、ポータル・クラスターがあるリモート・セルの名前でなく、ODR があるローカル・セルの名前にする必要があります。
  • ODR を使用して、静的および動的の両方のリモート・ポータル・クラスターにトラフィックを送付することもできます。そのためには、それぞれのターゲット・ポータル・クラスターに汎用サーバー・クラスターを定義します。詳しくは、下の「リモート ODR セルへの汎用サーバー・クラスターの定義」を参照してください。
    注: 垂直クラスター・メンバーを使用するリモートの静的クラスターに送付する場合、最後にオプションのステップを実行して、汎用サーバー・クラスター内の各ポートに、サーバー・カスタム・プロパティーを定義する必要があります。
重要: WebSphere Virtual Enterprise および WebSphere Application Server Network Deployment のバージョン・レベルをアップグレードするための保守を適用する場合、両方のアップグレードが完了するまでデプロイメント・マネージャーが非アクティブの状態になっていることが重要です。これは、両方のアップグレードが完了する前にデプロイメント・マネージャーがアクティブになると、WebSphere Virtual Enterprise の非互換バージョンが検出され、動的クラスターから一部の必要なリソースが除去されるからです。Network Deployment と WebSphere Virtual Enterprise の両方の更新が完了するまでデプロイメント・マネージャーを非アクティブにしておくと、この潜在的な問題は発生しません。

WebSphere Virtual Enterprise および ODR を準備する製品インストールの順序について詳しくは、製品をインストールするための WebSphere Application Server Network Deployment の準備を参照してください。

ODR の作成について詳しくは、ODR の作成と構成を参照してください。

クラスターでの保守

クラスターにおける IBM WebSphere Portal の保守とは、一般に、クラスター内の各ノードで、修正サービス (フィックスパックおよび interim fix) を適用したり、ソフトウェアのリリース・レベルを更新したりすること意味します。WebSphere Portal クラスターに修正サービスを適用する方法についての説明は、修正サービス・パッケージに付属しています。保守を行う前に必ずエンド・ユーザーに対する影響を分析し、保守フェーズの間であっても、サービスの提供が中断しないようにする (24x7 可用性ともいいます) 必要があります。

このセクションの説明では、修正において基本となる WebSphere Portal データベースが更新されない場合、 またはデータベース・サーバーやIBM WebSphere Application Server などの他のサポート・ソフトウェアに対するバージョンアップが必要ない場合には、 そのような修正を「マイナー」と分類します。 WebSphere Portal の大部分の Service Pack はマイナーとは見なされず、24x7 (1 日 24 時間、週 7 日) の可用性を保証するには、独立したインストール手順の使用が必要になる場合があります。

注: 水平のスケーリングを実装していない環境では (例えば、クラスターが垂直サーバーのみで構成されている場合)、再始動を必要とする修正により、エンド・ユーザーに対するサービスが一時的に停止します。 既存の 24x7 インストール手順は、このような環境には適用されません。
マイナー修正

クラスター環境の WebSphere Portal に対するすべてのマイナー修正は、修正に付属するインストール手順の説明を使用して、各クラスター・ノードに修正を単に適用することでデプロイできます。マイナー修正を適用するために、クラスターからノードを除去する必要はありません。除去すると、ノードをクラスターに戻すことができなくなる可能性があります。 以前にデプロイされているエンタープライズ・アプリケーションを更新する可能性のあるマイナー修正を適用するときには、修正を適用する前に、デプロイメント・マネージャーの自動同期機能を必ずオフにしてください。すべてのクラスター・ノードに修正をデプロイした後で、デプロイメント・マネージャーを使用して手動で強制的に同期を行い、ノード上のすべての更新の同期を取ることができます。その後、再び、自動同期機能を使用可能にします。

マイナー修正に関連する資料で WebSphere Portal またはWebSphere Application Server の再始動が要求されている場合は、必ず一度に 1 ノードずつマイナー修正を適用してください。このようにすることで、他のノードがエンド・ユーザーに対するサービスの提供を続けることができます。ただし、修正において WebSphere Portal データベースの更新が必要な場合は、修正を適用する前にクラスターの停止が必要になる場合があります。その場合は、24x7 の可用性を保証する手順を使用してください。

Service Pack

Service Pack を WebSphere Portal クラスター環境にインストールする複数のアプローチがあります。 推奨アプローチは、複数の実動クラスターを使用する方法です。 Service Pack のインストールには、IP スプレイヤーを変更してクラスターを受信側ユーザー要求から削除することが含まれます。これにより、既存のユーザー・セッションの処理を完了させ、そのクラスターをアップグレードしてすべてのノード上に Service Pack をインストールする時間が与えられます。 検証テストの結果、アップグレードされたクラスターが操作可能であることが確認された後、実動トラフィックの受信を開始し、一方で次のクラスターをオフラインにしてアップグレード・プロセスを行うことができます。 このアプローチは、アップグレード・プロセス中、24x7 (1 日 24 時間、週 7 日) の可用性を保持します。

24x7 (1 日 24 時間、週 7 日) の可用性を維持しながら、WebSphere Portal の Service Pack (フィックスパック) を既存のクラスターにインストールする場合のプロセスを説明する個別の文書が入手できます。 簡潔にこの手順を要約するために、IP スプレイヤーと Web サーバーを構成することにより、ユーザー・トラフィックのフローからノードまたはノードのセットを除去します。 その後、サービス・パックでノードをアップグレードします。 アップグレードが完了した後、ノードまたはノードのセットでこの手順を繰り返している間、 ノードまたはノードのセットをユーザー・トラフィックのフローに返します。 このプロセスは、クラスター内のすべてのノードをアップグレードするまで、続行されます。
重要: アップグレード・プロセス中、あるポートレットは、一時的に利用不可になることがあります。これは、以前のバージョンのポートレットとは非互換の、共有データベースへの更新を実行するためです。 これにより、このプロセスの使用時に、24x7 (1 日 24 時間、週 7 日) の可用性に対する機能的な制限が生じることがあります。

仮想環境の概要

仮想環境 (例えば VMWare ESX) を使用すると、実動サーバーの統合、中央管理、動的テスト環境といったユーザーのビジネス・ニーズを満たすことができます。 仮想環境は、オペレーティング・システム、アプリケーション、およびその上で作動するミドルウェアに対する透過性を提供します。

仮想環境で IBM WebSphere Portal を実行する際に留意する必要がある特別な考慮事項があります。 仮想マシンを最も有効活用できるのは、テスト・サーバーと開発サーバーが統合されていて、その中の複数の仮想マシンが物理マシン・リソースを共用できるだけでなく、どの時点においてもすべてのシステム・リソースが必要になるわけではないという前提の下で、それらのリソースを「過剰使用」することさえできるような状況です。 これは、仮想マシンが実動配信には使用できないという意味ではありません。ただしその場合、重要なリソースを過剰使用することがないよう、特別な注意を払う必要があります。 また、物理システムのメモリーと CPU の上に仮想マシンのコンテキスト切り替えとメモリー管理を処理する余分の処理層があるため、使用率が非常に高くなると、ネイティブ・インストール済み環境の場合と比較して、パフォーマンスが低下し始める可能性があります。 ご使用の仮想環境での WebSphere Portal のパフォーマンスを理解し、パフォーマンスの低下を補うために WebSphere Portal をどれだけ拡張するかを見極めるために、注意深いテストを行う必要があります。

仮想テスト環境および開発環境では、マシンの物理リソースを過剰使用することができます。 実稼働環境では、それぞれの仮想マシンが使用するための十分の物理 CPU とメモリーを確保してください。 メモリー所要量は、WebSphere Portal インスタンスの最大ヒープ・サイズを 2 倍にしたものを仮想マシンのメモリー構成として使用する、という指針が良いでしょう。 メモリー・ページングは、性能低下を招く可能性があるため、仮想マシン内でもハイパーバイザーにおいても、必ず避ける必要があります。

複数のプロファイルのサポート

IBM WebSphere Portal は、そのアプリケーション・サーバー構成 (データ・ソース定義、Web アプリケーションおよびポートレットのデプロイメント、Java 仮想マシン構成など) を表すアプリケーション・サーバー構成プロファイルを作成します。 構成プロファイルは、単一ポータル・インスタンスの全体の構成を表します。 複数のプロファイルにより、同一のインストールから、複数の独立して構成されたポータル・インスタンスを実行する機能が得られます。 WebSphere Portal バージョン 7 より前では、インストールごとに構成プロファイルが 1 つ (一般に、wp_profile という名前) しかありませんでした。

注: アプリケーション・サーバー・プロファイルについて詳しくは、z/OS 以外のオペレーティング・システムにおけるプロファイルの管理 を参照してください。
WebSphere Portal バージョン 7 から、デフォルト・プロファイルに加えて、追加のプロファイルを作成できるようになりました。このことは、以下の一般的なシナリオで有用です。
  • 複数の独立したポータル・インスタンスに対して、単一のインストールを再利用する (各種テストや開発作業のためなど)。
  • 製品を再インストールすることなく、現行プロファイルを削除してプロファイルを再作成することによって、構成の問題からリカバリーする。
  • カスタム・プロファイルを作成し、正規のスタンドアロン・インスタンスの重要でない余分なリソースを管理する必要をなくして、簡単にクラスターの能力を拡張する。
  • デプロイメント・マネージャー・プロファイルを更新して、ポータル・サーバーを処理するようにし、人手による準備ステップをすべて省く。
以下の各種プロファイル・タイプを生成できます。
portal.default
これは、収集された構成においてスタンドアロン・ポータル・サーバーを保持するプロファイルです。 これをスタンドアロン・サーバーとして使用したり、統合した後でポータル・クラスターの基本として使用したりします。
managed.portal
このカスタム・プロファイルは、ポータル・ランタイム環境により拡張されますが、サーバーは含まれません。 このプロファイルの主な目的は、追加クラスター・メンバーのランタイム環境として使用することです。 このカスタム・プロファイルの統合後、標準ポータル・タスクを使用して、既存のクラスター・テンプレートからポータル・サーバー・クラスター・メンバーを作成できます。
management.portal.augment
このプロファイルは、標準のデプロイメント・マネージャー・プロファイルを拡張することにより作成されます。 結果として生成されるプロファイルは、ポータルで使用するために作成されたデプロイメント・マネージャーを保持します。 これを使用すれば、人手による追加ステップの必要なく、直ちに他のポータル・プロファイルを統合できます。 大抵デプロイメント・マネージャーは別のハードウェアに配置されるので、この拡張テンプレートを別のインストール済み環境に移動させて、そこで実行する可能性があります。

検索コレクションおよび複数プロファイル

enable-profiles または replace-profiles タスクを実行する際、 既存の検索コレクションはすべて、プロファイル・テンプレートに取り込まれます。 検索機能では、複数のプロファイル間で検索コレクションを共用する機能はありません。 enable-profiles または replace-profiles タスクのいずれかを実行する前に、 デフォルトの検索コレクションを含むすべての検索コレクションを削除しておき、追加のプロファイルを作成時に検索エラーが生じるのを回避する必要があります。 バックアップおよび復元プロシージャーを使用して元のプロファイルにある検索コレクションを保存するか、または以下のエクスポートとインポートのステップを使用できます。
  1. 既存の検索コレクションをエクスポートします。
  2. 既存の検索コレクションを削除します。
  3. enable-profiles または replace-profiles 構成タスクを実行して、 プロファイル・テンプレートにあるポータル構成を取り込みます。
  4. 元のプロファイルにある保存された検索コレクションをインポートします。
  5. プロファイル・テンプレートを使用して、新しいプロファイルを作成します。新しいプロファイルにデフォルトの検索コレクションが自動的に作成されます。

クラスター環境やポータル・ファーム環境などにおいて、複数のポータル・サーバー・インスタンス間で検索コレクションを共用する場合、検索コレクションの共用をサポートするようにリモート検索サーバーを構成する必要があります。

クラスター構成についての特別な考慮事項

ベスト・プラクティスとしては、すべての保守をクラスター・レベルで管理する必要があります。 つまり、あるクラスターに対する保守の適用中には、そのクラスター全体のサービスを休止する必要があります。そうすれば、クラスター全体に関わる変更を行っても、エンド・ユーザーのトラフィックに影響を与えることがなく、 また、セル管理対象リソース (エンタープライズ・アプリケーションやポートレットなど) とローカル・ファイル・システム内の製品バイナリー間で、同期の競合を引き起こす可能性もなくなります。 連続可用性のある環境では、ある 1 つのクラスターに対してトラフィックが続行する間、別のクラスターがサービスを受けられるようにするために、複数のクラスターが必要であるかもしれません。

複数のプロファイルを使用する WebSphere Portal インストールの保守には、保守を製品バイナリーに適用すると共に、各プロファイル・インスタンスにもそれを適用することが含まれます。 矛盾が生じないよう、すべてのプロファイル・インスタンスおよび WebSphere Portal 製品バイナリーを同時に更新することが重要です。 特定のインストール上のプロファイルの 1 つが、あるクラスターに所属する場合には、そのクラスターが更新されるときには必ず、そのシステム上の共用 WebSphere Portal 製品バイナリーおよび他のすべてのプロファイルも更新して、同期を保守する必要があります。

したがって、1 セットの製品バイナリーを使用する複数のポータル・プロファイルが、クラスター構成の一部として使用される場合は、同じ製品バイナリーを共有するプロファイルすべてが同じクラスターに所属するようにして、クラスター・バウンダリーに保守を適用するベスト・プラクティスとの一貫性を保たせるよう強くお奨めします。

インストール方法、オプション、およびソース

複数のインストール方法 (サイレント、グラフィカル・ユーザー・インターフェース、およびコンソール)、オプション (ベースまたはフル)、およびソース (CD または CD イメージ) があります。

インストール・オプション

インストールのタイプには、フルとベースの 2 つがあります。

以下のいずれかのインストール・オプションを選択します。
注: IBM WebSphere Portal インストール・プログラムのビット・アーキテクチャーは、オペレーティング・システムのビット・アーキテクチャーに従うか、あるいは既存のサポートされている IBM WebSphere Application ServerWebSphere Portal がインストールされている場合は、インストールは WebSphere Application Server のビット・アーキテクチャーに従います。 例えば、64 ビットの Linux にインストールしている場合、WebSphere Portal は 64 ビット・バージョンとしてインストールします。32 ビットのアプリケーションを 64 ビットのオペレーティング・システムにインストールするように強制できます。詳しくは、「インストールの方法」を参照してください。
ベース
WebSphere Portal フィーチャーのベース・セットをデプロイするには、このオプションを選択します。このオプションによって、追加フィーチャー、サンプル、およびインストールの後に開発されたコンテンツを選択的に使用可能にして、ビジネス上の必要に応じてデプロイメントを作成することができます。
フル
製品で使用可能な WebSphere Portal フィーチャーおよびサンプルのフル・セットをデプロイするには、このオプションを選択します。このオプションによって、広範囲のフィーチャーの使用およびテスト、あるいは PoC (概念検証) デプロイメントの開発ができるようになります。

WebSphere Portal で提供されるポータル軽量モードにより、ポータルの始動時間が向上し、実稼働環境でのメモリー使用量を削減することが可能です。 詳しくは、「WebSphere Portal の構成」 > 「ポータルの動作の構成 (Configuring portal behavior)」 > 「ポータル軽量モードの使用 (Using portal light mode)」を参照してください。

インストール方法

ご使用の環境に該当するインストール方法を選択してください。 グラフィカル・インターフェース・プログラム、コンソール・モード、または応答ファイル (サイレント・インストールの場合) のいずれかを使用できます。

グラフィカル・ユーザー・インターフェース
グラフィカル・ユーザー・インターフェース・プログラムでは、ホスト名やノードなどの必須の情報が収集された後、インストールが実行されます。オペレーティング・システムによっては、グラフィカル・ユーザー・インターフェースをサポートしないものがあります。
コンソール・モード
コンソール・モードは、グラフィカル・ユーザー・インターフェース・プログラムのテキストによる表示です。 選択肢に対応する数字を入力した後、Enter キーを押してインストールを進めます。
サイレント・インストール
サイレント・インストールでは、ユーザーとの対話なしでインストール・オプションを提供するための応答ファイルが使用されます。 このオプションは、IBM WebSphere Portal を複数のマシンに対して同様の設定でインストールまたはアンインストールする場合に使用します。 インストールを構成するには、インストール・タスクを実行する前に応答ファイル内のオプションを変更します。
インストールに関する注意: インストール前に、以下の情報をお読みください。
  • すべてのインストール方法に対して以下を適用してください。
    • インストールまたはアンインストールを開始する前に、マシン上で稼働しているスクリーン・セーバー・ソフトウェアを 使用不可またはオフにしてください。このソフトウェアは、マシンのネットワークへの接続能力に影響し、インストール・プログラムの動作を妨害することがあります。
    • インストール前にインストール・プログラムで、オペレーティング・システムとその前提条件、 使用できるディスク空き容量、および必須ソフトウェア前提条件が検証されます。
    • 異なる複数のディレクトリーにインストールするのであっても、サーバーの 2 つのインスタンスを同時にインストールすることはできません。 次のサーバーをインストールする前に、それぞれのサーバーのインストールを完了しなければなりません。
    • インストール・ディレクトリーには、ファイルが含まれていないディレクトリーを指定してください。
    • インストール・ディレクトリーには、以下の文字が含まれていないディレクトリーを指定してください。
      • ~
      • !
      • @
      • #
      • $
      • %
      • ^
      • &
      • *
      • (
      • )
      • _
      • +
      • {
      • }
      • |
      • <
      • >
      • ?
      • `
      • =
      • [
      • ]
      • ;
      • '
      • ,
      • .
      • "
  • グラフィカル・ユーザー・インターフェースとコンソール・モードの両方の方法に対して 以下を適用してください。
    ホスト名が間違って表示されている場合 (例えば serve1.server1.rtp.raleigh.ibm.com など)、 正しい情報に訂正する必要があります (例えば、serve1.server1.rtp.raleigh.ibm.comserver1.rtp.raleigh.ibm.com に変更するなど)。
    注: この動作が見られるのは、Microsoft Exchange サーバーのインスタンスが既にインストールされている Windows サーバーで、インストールが実行されるときのみです。
  • グラフィカル・ユーザー・インターフェースの使用時にのみ以下を適用してください。
    • ダイアログが表示され、テキストの入力が必要な場合は、入力フィールド間を移動するのに、 ポインティング・デバイスを使用するか、または TAB キーを押す必要があります。

64 ビット・オペレーティング・システムでの 32 ビット・インストール

32 ビット・インストールを 64 ビット・オペレーティング・システムにインストールするには、次のいずれかの方法を選択してください。

表 28. 64 ビット・オペレーティング・システムでの 32 ビット・インストール方法
メソッド 指示
手動インストール 32 ビット IBM WebSphere Application Server 製品を手動でインストールします。 次に、WebSphere Portal を 既存の WebSphere Application Server インストール済み環境にインストールします。
重要: Solaris バージョン 9 オペレーティング・システムで、この手動インストールを選択する場合は、必ず 32 ビット WebSphere Application Server 製品を手動でインストールして、インストーラーが自動的に 64 ビット環境を選択しないようにしなければなりません。
コマンド行インストール install.bat|sh -W defaults.force32bit=true コマンドを入力して、64 ビット・オペレーティング・システムに 32 ビット WebSphere Application Server および WebSphere Portal をインストールします。
注: このコマンドは、WindowsAIXzLinuxおよび Solaris バージョン 9 オペレーティング・システムのみでサポートされています。
重要: Solaris バージョン 9 オペレーティング・システムがある場合は、必ずこのコマンドを入力して、インストーラーが自動的に 64 ビット環境を選択しないようにしなければなりません。
IBM i の場合に重要: IBM i および J9 32 ビット JVM がインストールされている場合は、-W enableClassicJVM.active=false パラメーターをコマンド行に入力して、クラシック 64 ビット JVM の代わりに J9 32 ビット JVM を使用してポータル・サーバーをインストールできます。

インストール・ソースの場所

IBM WebSphere Portal のインストールの前に、ご使用の環境に最適なインストール・ソースの場所と方法を選択します。例えば、DVD-ROM またはファイル・システムからインストールすることができ、グラフィカル・インターフェース・プログラムを使用したインストールや、サイレント・インストールを実行することもできます。

注: ディスク・イメージがサポートしている同じプラットフォーム上で、そのイメージをダウンロードし、抽出し、インストールする必要があります。例えば、Linux プラットフォームにインストールする準備をしている場合には、Linux システム上で Linux イメージをダウンロードし、抽出し、インストールする必要があります。
インストール・ソースの選択時には、インストール時間が異なる可能性があるため、ローカルの環境を考慮に入れる必要があります。以下のソースの場所のいずれかを選択します。
DVD からインストールする
このオプションには以下の利点があり、インストールを限られた回数で実行する場合に最適です。
  • インストール前に前提条件ステップは必要ない。
  • ファイル・サーバーが使用できない、もしくは使用できるが DVD よりも遅い場合、インストール・パスを提供する。
Linux での注: セキュリティー上の理由で、Red Hat Enterprise Linux バージョン 5 などの一部の Linux バージョンでは、 自動マウントの DVD からはプログラムを実行できません。 ユーザーのシステムがこれに該当する場合、DVD からはインストーラーを実行できません。 この問題を修正するには、/etc/fstab ファイルの最後に /dev/hdc /media/ auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 行を追加して、システムのファイル・システム・テーブルを更新します。
DVD のコンテンツをローカル・マシンにコピーする
このオプションはネットワークあるいは DVD-ROM の速度に依存せず、同じ製品を同じマシンに繰り返しインストールする場合に最適です。
DVD のコンテンツをローカル・マシンにコピーするには、次のステップを実行します。
  1. その製品用のディレクトリーを作成する。例えば version_number
  2. DVD を独自のディレクトリーにコピーする。例えば /wpversion_number/OS_code-Setup
オペレーティング・システムのコードは、以下のとおりです。
  • AIX (32 ビットおよび 64 ビット) = A
  • IBM i = I
  • Intel Linux (32 ビットおよび 64 ビット) = IL
  • PowerPC Linux (32 ビットおよび 64 ビット) = PL
  • zLinux (64 ビット) = ZL
  • Solaris (32 ビットおよび 64 ビット) = SS
  • Solaris (64 ビット) = SO
  • Windows (32 ビットおよび 64 ビット) = W
注: (UNIX のみ) コンテンツのコピー後に、インストールを実行するユーザーに読み取り権限と実行権限を設定してください。
DVD のコンテンツをファイル・サーバーにコピーする
ネットワーク・ドライブからのインストールは、DVD-ROM ドライブからのインストールよりも速い場合がある。
DVD のコンテンツをファイル・サーバーにコピーするには、次のステップを実行します。
注: この 方式を使用して WebSphere PortalWindows クライアントにインストールする際には、ファイル・サーバーをドライブ名にマウントしなければなりません。UNC リソース (//servername/mountpoint) にはドライブ名が割り当てられていないので、このリソースからはインストールできません。 インストールの間にセキュリティー関係のプロンプトが出されるのを抑制するため、Windows の信頼できるサイトのリストにネットワーク・ファイル・サーバーを追加することが必要になることもあります。
  1. その製品用のディレクトリーを作成する。例えば version_number
  2. DVD を独自のディレクトリーにコピーする。例えば /wpversion_number/OS_code-Setup
オペレーティング・システムのコードは、以下のとおりです。
  • AIX (32 ビットおよび 64 ビット) = A
  • IBM i = I
  • Intel Linux (32 ビットおよび 64 ビット) = IL
  • PowerPC Linux (32 ビットおよび 64 ビット) = PL
  • zLinux (64 ビット) = ZL
  • Solaris (32 ビットおよび 64 ビット) = SS
  • Solaris (64 ビット) = SO
  • Windows (32 ビットおよび 64 ビット) = W
注: (UNIX のみ) コンテンツのコピー後に、インストールを実行するユーザーに読み取り権限と実行権限を設定してください。

拡張インストール・パラメーター

インストール・コマンドに以下のパラメーターを追加して、ビジネス要件に合うようインストールをカスタマイズできます。

「ポート構成」パネルの表示

-W adminPortBlock.active=false -W portalPortBlock.active=false
GUI またはコンソール・モード・インストール・コマンドに以下のパラメーターを追加して、GUI またはコンソール・モード・インストール・プログラムで「ポート構成」パネルを表示する。

WebSphere Application Server ポート範囲の指定

-W adminPortBlockInput.startingPortToScan=port number -W adminPortBlockInput.endingPortToScan=port number -W adminPortBlockInput.portBlockSize=block size
このパラメーターをサイレント・インストール・コマンドに追加して、スキャンする WebSphere Application Server ポートの範囲、およびポート・ブロック・サイズを指定する。
注: デフォルトでは、インストール・プログラムは、WebSphere Application Server について、アクティブ・ポートのスキャンを 10000 から開始して 65000 で終了します。
注: WebSphere Application Server のポート・ブロック・サイズを 25 個より少なくすることはできません。

IBM WebSphere Portal ポート範囲の指定

-W portalPortBlockInput.startingPortToScan=port number -W portalPortBlockInput.endingPortToScan=port number -W portalPortBlockInput.portBlockSize=block size
このパラメーターをサイレント・インストール・コマンドに追加して、スキャンする IBM WebSphere Portal ポートの範囲、およびポート・ブロック・サイズを指定する。
注: デフォルトでは、インストール・プログラムは、WebSphere Portal について、アクティブ・ポートのスキャンを 10000 から開始して 65000 で終了します。
注: WebSphere Portal のポート・ブロック・サイズを 25 個より少なくすることはできません。

特定の PortalServer と AppServer のインストール場所の指定

-W was.location="/proj/WebSphere/portal/AppServer" -W portal.location="/proj/WebSphere/portal/PortalServer" -W setNewWasInstallLocationValue.active="false"
これらのパラメーターをインストール・コマンドに追加して、PortalServer と AppServer のインストール・ディレクトリーをカスタマイズする。

ポート・ファイルの変更

-W adminPortBlockInput.portsFilePath=full path to ports file
このパラメーターをインストール・コマンドまたは応答ファイルに追加して、ポート・ファイル WASDefaultPortsFile.props を変更する。このファイルは、セットアップ・ディスクにあり、 WebSphere Application Server ポート範囲を持ちます。
注: WebSphere Application Server の有効なポート範囲は、1 から 65535 です。
-W portalPortBlockInput.portsFilePath=full path to ports file
このパラメーターをインストール・コマンドまたは応答ファイルに追加してポート・ファイル WPDefaultPortsFile.props を変更する。このファイルは、セットアップ・ディスクにあり、WebSphere Portal ポート範囲を持ちます。
注: WebSphere Portal の有効なポート範囲は、1 から 65535 です。

プロファイルをデフォルト・プロファイルとして設定

-W detectProfileAction.isDefault="True"
共存インストールをインストールする場合は、インストール・コマンドにこのパラメーターを追加して、プロファイルをデフォルト・プロファイルとして設定する。
-W detectProfileAction.isDefault="False"
共存インストールをインストールする場合は、インストール・コマンドにこのパラメーターを追加して、プロファイルを非デフォルト・プロファイルとして設定する。
-W detectProfileAction.isDefault="True" -W detectProfileAction.profileName="your_profile_name" -W detectProfileAction.profilePath="C:¥full¥path¥your_profile_name"
共存インストールをインストールする場合は、インストール・コマンドに次の 3 つのパラメーターを追加して、デフォルトのプロファイル名とプロファイル・パスを変更する。

cellName の設定

-W cellName.value=cellName
デフォルトで、インストールは CellNameNodeName に設定する。 このパラメーターを使用して、デフォルトを、ユーザーのビジネス要件に適合するものに変更します。

IBM i ポート構成およびプロファイル名

-W setWASHome.startingPort=20000
i の場合: このパラメーターを追加して、ポート構成を指定する。
-W setWASHome.wasProfile=my_profile
i の場合: このパラメーターを追加して、デフォルトを使用する代わりにプロファイル名を設定する。

AIX でのインストール

IBM WebSphere Portal は、機能の検査とテストができる PoC (概念検証) から使い勝手がよく拡張が容易な実稼働環境まで、柔軟なデプロイメント・オプションを提供します。

このタスクについて

重要: WebSphere Portal のインストール後に、マッシュアップ統合の使用を計画している場合は、「マッシュアップ統合」 > 「ポータルおよびマッシュアップの構成」 > 「ポータルでのマッシュアップ統合の使用可能化」のトピックにリストされている deploy-portal-mashup-ui タスクを実行する必要があります。
オプションのリストから必要なセットアップのタイプを選択します。 シナリオに従い WebSphere Portal をインストールして構成します。

AIX でのスタンドアロン・サーバーのセットアップ

堅固なクラスター環境が必要でない場合には、スタンドアロン実稼働環境をセットアップします。また、デプロイメントのニーズを判別して検証するには、スタンドアロン・サーバーのデプロイメントが役に立ちます。このデプロイメントにより、ビジネス目標を達成する方法を決定するため、機能とフィーチャーを検討し、テストすることができます。

このタスクについて

以下の図は、このシナリオの指示に従った結果のスタンドアロン・サーバー構成を説明しています。
リモート・データベース、LDAP サーバー、および HTTP サーバーのあるスタンドアロン構成の図
ベスト・プラクティス パフォーマンスを改善するために、インストールの完了後に、ポータル環境でサーバーを調整することを忘れないでください。 「IBM WebSphere Portal and IBM Lotus Web Content Management Performance Tuning Guide」の「Base Portal Tuning」のシナリオには、IBM WebSphere Application ServerWebSphere Portal サービス、データベース、ディレクトリー・サーバーなどのチューニングに関する情報が記載されています。

AIX オペレーティング・システムの準備

IBM WebSphere Portal 用のオペレーティング・システムのセットアップに関する情報を示します。 他のコンポーネントを使用する場合は、追加のステップが必要になる場合があります。 詳しくは、インストールする特定のコンポーネントの製品資料を参照してください。

このタスクについて
AIX マシンを準備するには、以下のステップを実行します。
手順
  1. ファイル記述子の限度を 10240 に設定します。例: ulimit -n 10240
  2. Web Content Management のみ: ulimit -f コマンドを使用して、作成可能なファイルの最大サイズを、コンテンツ・サーバーにアップロードする必要がある最大ファイルのサイズ以上に設定します。
    コマンド ulimit -f unlimited は、ファイル・サイズの制限を除去します。
  3. X サーバーを AIX (例えば X-Windows または GNOME) にインストールして構成し、インストール・プログラムが提供するグラフィカル・ユーザー・インターフェースを使用できるようにします。
    注: 応答ファイルを使用するかまたはコンソール・モードでインストールしている場合は、X サーバーは必要ありません。

AIX スタンドアロン: WebSphere Portal のインストール

IBM WebSphere Portal は、情報を保管するための統合データベースを完備した、単一のコンポーネントとしてインストールされます。したがって、WebSphere Portal を素早く稼働状態にし、PoC (概念検証) フェーズに入り、すぐに作成と処理を開始することができます。また、ご使用の環境を拡張して、高可用性フェイルオーバー、さらに堅固なデータベース、および LDAP ベースの認証を組み込むこともできます。

始める前に
使用しているオペレーティング・システムに関する WebSphere Portal の詳細なシステム要件を検討し、WebSphere Portal をインストールする前に、すべてのハードウェアおよびソフトウェアが最小の製品レベルを満たしていることを確認してください。 インストール方法、オプション、およびソースを検討します。
このタスクについて
WebSphere Portal をインストールするには、以下のステップを実行します。
手順
  1. コマンド行で ping yourserver.yourcompany.com と入力し、完全修飾ホスト名が適切に構成されていることを確認してください。
  2. コマンド行で ping localhost と入力し、ネットワークが適切に構成されていることを確認してください。
  3. 既存の WebSphere Application Server インスタンスを使用してインストールする場合は、そのインスタンスがサポートされているレベルでインストールされていること、および以下の機能がインストール済みであることを確認してください。
    • アプリケーション・サーバー
    • 管理
      • スクリプトによる管理
      • 管理コンソール
    • Ant およびデプロイメントのツール
      • デプロイ・ツール
      • Ant ユーティリティー
    制約事項: 既存の WebSphere Portal バージョン 7.0 プロファイルが含まれる、または正しいソフトウェア・バージョンと一致しない WebSphere Application Server のインストールは、使用可能な既存の WebSphere Application Server インスタンスのリストに含まれません。
    重要: 既存の WebSphere Application Server インスタンスがサポートされているレベルであることを確認することに加えて、ApacheDerby がサポートされているレベルでインストールされていることを確認してから、WebSphere Portal をインストールする必要があります。サポートされているレベルについては、WebSphere Portal の詳細なシステム要件を参照してください。
  4. オプション: root 以外のユーザーを使用して WebSphere Portal をインストールする場合は、以下のステップを実行します。
    制約事項: root 以外のユーザーとして WebSphere Application Server をインストールすることもできますが、このオプションには WebSphere Portal の機能に影響を及ぼす可能性がある制限があるので、root ユーザーとして WebSphere Application Server をインストールする必要があります。
    1. 現在サポートされているバージョンの WebSphere Application Server を、root ユーザーでインストールします。
    2. コマンド・プロンプトを開き、以下のステップを実行して、非 root ユーザーの作成と所有権の変更を行います。
      1. 適切なシステム・コマンドを使用して、新規グループの作成、新規ユーザーの作成、新規グループへの新規ユーザーの追加を行います。
      2. 以下のタスクを実行して、非 root ユーザーの権限を変更します。
        chmod -R g+rwx /usr/IBM
        chgrp -R group_name /usr/IBM
        chmod -R g+wr /tmp
        chgrp -R group_name /tmp
        chmod -R g+wr /var/tmp
        chgrp -R group_name /var/tmp
      3. root 以外のユーザーとしても WebSphere Application Server をインストールしている場合は、32 ビットまたは 64 ビットのいずれの AIX オペレーティング・システムを使用しているかに基づいて、以下のいずれかの追加タスクを選択します。
        表 29. オペレーティング・システムのタイプに基づく追加のアクセス権タスク
        オペレーティング・システムのタイプ 追加タスク
        32 ビット・オペレーティング・システム
        chmod -R g+rwx /A-Setup
        chgrp -R group_name /A-Setup
        64 ビット・オペレーティング・システム
        chmod -R g+rwx /A-Setup
        chgrp -R group_name /A-Setup
    3. 次のステップに従ってインストール・プログラムを起動します。インストール中に、root 以外のユーザーを使用して既存の WebSphere Application Server を選択します。インストールの場所は、非 root ユーザーがアクセス権を認可されているパスにある固有の場所に設定します。
  5. WebSphere Portal のインストールに使用するインストール方法に基づいて、以下のいずれかのインストール・コマンドを選択します。詳しくは、『インストール方法』を参照してください。
    拡張インストール・パラメーター: インストールをカスタマイズするには、インストール・コマンドにさまざまなパラメーターを追加できます。例えば、ポート情報を指定できます。詳しくは、この文書の最後にある関連参照の『拡張インストール・パラメーター』を参照してください。
    制約事項: インストール・パスの定義時にサポートされる文字は、ASCII 文字 [A から Z および a から z]、数値 [0 から 9]、スラッシュ [オペレーティング・システムに応じて / または ¥]、およびダッシュ [-] のみです。
    表 30. インストール・タスク・オプション
    インストール・タイプ タスク
    グラフィカル・ユーザー・インターフェース ./install.sh
    コンソール・モード ./install.sh -console
    サイレント・インストール ./install.sh -options "path_to_file/response_filename" (ここで、path_to_file は応答ファイルへの絶対パス、response_filename はファイルの名前です)。 サンプルのインストール応答ファイル (installresponse.txt) と サンプルのアンインストール応答ファイル (uninstallresponse.txt) は、 セットアップ CD のルート・ディレクトリーにあります。
    重要: 応答ファイルのパスにスペースが含まれないようにしてください。 また、そのファイル名の中にスペースを含めないようにしてください。
    注: 存在することがわかっている WebSphere Application Server インスタンスがインストール・プログラムで検出されない場合は、インストール・プログラムを終了してから次のコマンド行を使用して WebSphere Application Server インスタンスの場所を渡します。例: ./install.sh -W was.undetectedWas="/my/WAS/location"
    注: GUI またはコンソール・モード・インストール・プログラムで WebSphere Application Server または WebSphere Portal の ポートを検出できない場合は、警告メッセージが表示され、値を入力する別の画面が表示されます。 サイレント・インストールで WebSphere Application Server または WebSphere Portal のいずれかのポートの検出に失敗した場合、インストーラーは終了します。
  6. インストールが成功したことを確認する。 http://yourserver:yourport/wps/portal フォーマットを使用して WebSphere Portal にアクセスする。 wp_profile_root/ConfigEngine ディレクトリーから以下のいずれかのタスクを実行して、server1_PortMatrix.txt ファイルと WebSphere_Portal_PortMatrix.txt ファイルを生成します。
    注: ポート・ファイルは wp_profile_root/ConfigEngine/log/ ディレクトリーにあり、このファイルには、インストールの対象となる WebSphere Application Server (server1) と WebSphere Portal (WebSphere_Portal) のポートがリストされています。
    • ./ConfigEngine.sh list-server-ports -DWasPassword=password
    • ./ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
    • ./ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal -DWasPassword=password
  7. オプション: WebSphere Portalのインストールが正常に完了した後に、インターネットやイントラネットのサンプル・サイトなどの IBM Lotus Web Content Management のサンプル・コンテンツを使用可能にする場合は、wp_profile_root/ConfigEngine ディレクトリーから ./ConfigEngine.sh configure-express -DPortalAdminPwd=password -DWasPassword=password タスクを実行します。
    制約事項: configure-express タスクは、データベース、ユーザー・レジストリー、コンテキスト・ルート、セキュリティーなどを構成する前に実行してください。インストール・タスク以外のタスクを既に実行した場合は、このタスクを実行しないでください。
    注: サンプル・コンテンツの使用方法に関するチュートリアルについては、『サンプル・サイト・テンプレートの探索』を参照してください。 このファイルへのリンクは、この文書の最後にあります。
    以下のようなサンプル・コンテンツがあります。
    • contentAuthors というグループを作成する。このグループのメンバーには、サンプルのインターネット・サイトとイントラネット・サイトでコンテンツを作成する特権が与えられます。「管理」領域にナビゲートして、「アクセス」 > 「ユーザーおよびグループ」をクリックします。
    • 新規 Web Content Management ライブラリーとして、「Internet Web Content 7.0.0」と「Intranet Web Content 7.0.0」の 2 つを作成する「管理」領域にナビゲートして、「ポータル・コンテンツ」 > 「Web コンテンツ・ライブラリー」をクリックします。
    • ポートレット・フィルターを追加し、サンプルのインターネット・サイトとイントラネット・サイトのさまざまなポートレットにそのフィルターを適用する。WebSphere Application Server 管理コンソールでフィルターの定義を確認し、「環境」領域でカスタム・リソースを調べることができます。
    • テーマ・ポリシーとして、InternetStyle と IntranetStyle の 2 つを作成する。これらのスタイルは、サンプルのインターネット・サイトとイントラネット・サイトに適用されます。「テーマ・カスタマイザー」にナビゲートして、スタイルを選択します。
    • Web Content Management レンダリング・ポートレットのポートレット・クローンを数個作成する。これらのポートレット・クローンは、サンプルのインターネット・サイトとイントラネット・サイトで使用されます。
    • コンテキスト・ルートが wps/portal/intranet および wps/portal/internet の仮想ポータルを 2 つ作成する。 これらは、サンプルのインターネット・サイトとイントラネット・サイトです。http://yourserver:yourport/wps/portal/internet および http://yourserver:yourport/wps/portal/intranet に移動してアクセスします。
    • 「E メールのデフォルト・スロット」、「フィードのデフォルト・スロット」、「各種のデフォルト・スロット」、「Web クリッピングのデフォルト・スロット」、および「Web Content Management のデフォルト・スロット」など、いくつかのサンプル・クリデンシャル・スロットを作成する。「管理」領域にナビゲートし、「アクセス」 > 「クリデンシャル・ボールト」 > 「システム・ボールト・スロットの管理」をクリックします。
  8. オプション: configure-express タスクを実行すると、インターネットおよびイントラネット・サイト・テンプレートのコンテンツを含む Web コンテンツ・ライブラリー内の項目の所有者が uid=xyzadmin,o=defaultWIMFileBasedRealm としてリストされます。これらの項目の所有者情報を更新してポータル・アドミニストレーター ID に対応させるには、以下のステップを完了します。
    1. wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties ファイルを編集する。
    2. 以下の行をファイルに追加する。
      uid=xyzadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
      portal_admin_DN は、ポータル・アドミニストレーターの識別名で、content_authors_group_DN は、LDAP 構成中に使用されるコンテンツ作成者グループの識別名です。
      重要:
      • portal_admin_DN に指定するポータル・アドミニストレーターは、必ず content_authors_group_DN に指定するグループのメンバーであるようにしてください。 そうでない場合、ポータル・アドミニストレーターは、イントラネットおよびインターネット・サイトのテンプレートの Web コンテンツ・ライブラリーにアクセスできません。
      • 複数のレルムがある環境で express-memberfixer タスクを実行する場合は、cn=contentauthors,o=defaultWIMFileBasedRealm グループを削除します (存在する場合)。 複数のレルムがある環境にこのグループが存在すると、メンバー・フィクサー・タスクは無効になります。
    3. 変更を保管してファイルを閉じる。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ./ConfigEngine.sh express-memberfixer -DPortalAdminPwd=password -DWasPassword=password タスクを実行する。
  9. オプション: WebSphere Application Server または WebSphere Portal のポートを変更する必要がある場合は、以下のステップを実行します。
    注: modify-ports-by-startport タスクを正常に完了するためには、開始ポート・パラメーターが必要です。 開始ポートを指定すると、このポートがポート値を割り当てるためのベースになります。 各ポートが割り当てられるに従い、コードはこの値を増分します。 つまり、WebSphere Application Server のポートは、modify-ports-by-startport タスクで定義されたポートから始まり、増分的に割り当てられます。
    1. server1 および WebSphere_Portal サーバーを停止する。
    2. 変更する必要のあるサーバーごとに、次のコマンドのいずれかを実行する。
      表 31. 開始ポート番号を使用してポート番号を変更するコマンド
      メソッド タスク
      開始ポート番号 ./ConfigEngine.sh modify-ports-by-startport -DWasPassword=password -DModifyPortsServer=servername -DStartPort=starting port number
      ポート・ファイル
      注: サンプル・ポート・ファイルはセットアップ・ディスクにあります。
      ./ConfigEngine.sh modify-ports-by-portsfile -DWasPassword=password -DModifyPortsServer=servername -DPortsFile=full path to ports file
      ポート・ファイル内の情報の例を以下に示します。ただしポート値は、ご使用の環境に基づいて異なります。
      BOOTSTRAP_ADDRESS=10035
      SOAP_CONNECTOR_ADDRESS=10025
      ORB_LISTENER_ADDRESS=10034 
      SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=10041
      CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=10036
      CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=10033
      WC_adminhost=10042
      WC_defaulthost=10039
      DCS_UNICAST_ADDRESS=10030
      WC_adminhost_secure=10032
      WC_defaulthost_secure=10029
      SIP_DEFAULTHOST=10027
      SIP_DEFAULTHOST_SECURE=10026
      IPC_CONNECTOR_ADDRESS=10037
      SIB_ENDPOINT_ADDRESS=10028
      SIB_ENDPOINT_SECURE_ADDRESS=10038
      SIB_MQ_ENDPOINT_ADDRESS=10040
      SIB_MQ_ENDPOINT_SECURE_ADDRESS=10031
    3. server1 および WebSphere_Portal サーバーを再起動する。
次のタスク
インストールの直後に追加の WebSphere Portal プロファイルを作成してから、各プロファイルを個々に構成することができます。 あるいは、引き続き WebSphere Portal 環境を構成してから複数のプロファイルを作成し、各プロファイルの構成が同じになるようにすることもできます。

AIX スタンドアロン: データベースを使用するための WebSphere Portal の構成

デフォルトのデータを実動データベース・サーバーに転送する前に、データベース・サーバーを準備する必要があります。 データベースの準備には、ユーザー ID およびデータベースの作成が含まれます。 このインストール・パスのスタンドアロン実動サーバーの場合、リモート・データベース・サーバーが使用されます。

このタスクについて
使用しているデータベース・サーバーを選択します。
AIX スタンドアロン: DB2 データベースのセットアップ

ここでは、WebSphere Portal と 連動させるための DB2 の インストールとセットアップについて説明します。

AIX スタンドアロン: DB2 のインストール

ここでは、WebSphere Portal と連携して稼働させるための DB2 のインストールについて説明します。

始める前に

始める前に

  • DB2 技術サポートにある「DB2 Quick Beginnings」ガイドに示されている推奨事項に従って、オペレーティング・システムが、更新済みのカーネル・パラメーターを使用してセットアップされていることを確認してください。
  • DB2 のインストール・プログラムを使用して DB2 をインストールする場合は、 正しいオペレーティング・システム権限のある DB2 管理ユーザーが自動的に作成されます。
  • DB2 インスタンスのホーム・ディレクトリーに必要な データベースを作成できるだけの十分なディスク・スペースがあることを確認してください。
手順
  1. DB2 または DB2 クライアントと、 必要なフィックスパックをインストールするには、 DB2 の資料の手順に従う。
  2. DB2WebSphere Portal 以外のシステムにインストールされている場合、 以下の手順を実行する。
    • JDBC タイプ 2 ドライバーのみ: 適切な DB2 クライアントを、 WebSphere Portal と同じシステムにインストールし、サーバー・プロファイル名と 同じ名前にする必要があります。
    • JDBC タイプ 4 ドライバーのみ: ドライバー JAR ファイルをポータル・サーバーにコピーします。 これらのドライバー・ファイルは、次の例のように、 wp_profile_root ディレクトリー内に置くことをお勧めします。
  3. DB2 システムでサービス・ファイルを開く。 DB2 のインストール時に、DB2 インスタンス・ポートが サービス・ファイルに追加されたことを確認します。
    • テキスト・エディターを使用して、ファイル /etc/services を開く。
    • DB2_db2inst1 50000/tcp (db2inst1 は DB2 インスタンス名) が サービス・ファイル内にあることを確認する。DB2_db2inst1 50000/tcp が サービス・ファイル内にない場合は、この項目をサービス・ファイルに追加します。
      注: 使用するポート番号が使用中ではないことを確認します。ポート番号がすでに使用中である場合は、 他のポート番号を選択してください。
  4. タイプ 2 モードで JDBC ドライバーを使用している場合は、ご使用の DB2 クライアントを以下のコマンドを使用して構成する。 リモート・データベースを使用している場合は、この手順を WebSphere Portal のインストールとは別に行ってください。
    • db2 update dbm cfg using tp_mon_name WAS
    • db2 update dbm cfg using spm_name hostname。 ここで、hostname は、WebSphere Portal のホスト名です。
    spm_name のデフォルトはホスト名それ自体であるので、hostname パラメーターの指定はオプションです。ホスト名が 8 文字を超えている場合は、 空の二重引用符 (" ") を使用してください。例えば、db2 update dbm cfg using spm_name " " のようにします。
AIX スタンドアロン: グループの作成およびユーザーの割り当て

データベースを DB2 に転送する前に、 まず、wkplc_dbdomain.properties で指定したユーザーおよびグループを作成し、 そのユーザーを該当するグループに割り当てる必要があります。ユーザー名およびグループ名は、 データベース管理システムのソフトウェア要件と WebSphere Portal 要件の両方に準拠している必要があります。

手順
  1. dbdomain.DbUser のユーザーを作成します。 wkplc_dbdomain.properties ファイルで、ランタイムのデータベースへの接続に ランタイム・ユーザーを使用することを示す値を入力した場合は、 dbdomain.DbRuntimeUser のユーザーを作成します。これらのユーザーを作成する際は、 wkplc_dbdomain.properties ファイルで入力したのと同じユーザー ID およびパスワードを使用します。
  2. dbdomain.DbConfigRoleName のグループを作成します。 wkplc_dbdomain.properties ファイルで dbdomain.DbRuntimeRoleName の値を入力した場合、 dbdomain.DbRuntimeRoleName のグループを作成します。
  3. 作成した dbdomain.DbUser のユーザーを、 作成した dbdomain.DbConfigRoleName のグループに割り当てます。
  4. dbdomain.DbRuntimeUser が指定されている場合は、 作成した dbdomain.DbRuntimeUser のユーザーを 作成した dbdomain.DbRuntimeRoleName のグループに割り当てます。
AIX スタンドアロン: DB2 のデータベース・プロパティーの変更

デフォルトのデータベースから DB2 データベースにデータを転送する前に、適切なプロパティー・ファイルを変更する必要があります。

このタスクについて
プロパティー・ファイルに関する作業:
  • 複数のデータベースを使用して、Feedback、LikeMinds などのアプリケーションの情報を保持することができます。 例えば、次のようなプロパティー値を使用します。
    • release.DbName=reldb
    • jcr.DbName=jcrdb
    • feedback.DbName=fdbkdb
    • likeminds.DbName=lmdb
    • community.DbName=commdb
    • customization.DbName=custdb
  • リモート・データベースを使用している場合は、 リモート・サーバーに対応した値を入力してください。
  • プロパティー・ファイル中のファイル・システム・パスでは、使用するオペレーティング・システムとは無関係に、円記号 (¥) ではなく、スラッシュ (/) を使用してください。
  • 以下に示すプロパティーの他に、追加のデータベース・プロパティーがある場合があります。 このタスク内のプロパティーのみ変更し、他のプロパティーはすべてスキップしてください。
  • 以下にイタリックで表示されている値は、特定の環境に対して変更が必要な場合があります。
  • プロパティーごとのリストに記載されている推奨値は、ターゲット・データベースに対して WebSphere Portal を構成するために必要な固有の情報を表しています。
  • どのデータベース・ドメインを構成する必要があるかに応じて、dbdomain を以下の値に置き換えます。
    • release
    • customization
    • community
    • jcr
    • feedback
    • likeminds
  • release、customization、community、および JCR の各ドメインに対して、次のプロパティーの少なくとも 1 つが固有の値である必要があります。
    • dbdomain.DbName
    • dbdomain.DbUrl
    • dbdomain.DbSchema
    release、customization、community、および jcr の各ドメインにわたって、この 3 つのプロパティーすべてに同じ値を使用すると、データベース・オブジェクト名があいまいになるため、データベース転送タスクは失敗します。
  • DbUserDbUrl、 および DbPassword がドメイン間にわたって同じではない場合は、DataSourceName の値をその他のドメインの DataSourceName とは異なる値にする必要があります。 つまり、この値はデータベース・ドメインでは固有でなければなりません。
手順
  1. 次のファイルを見つけ、それぞれのバックアップ・コピーを作成してから、値の変更を行う。
    • wp_profile_root/ConfigEngine/properties/wkplc.properties
    • wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties
    • wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties
    • Derby 以外のデータベースから転送する場合は: wp_profile_root/ConfigEngine/properties/wkplc_sourceDb.properties

    デフォルト値は、これらのファイル内にリストされています。特に注がない限り、すべての値のタイプは英数字のテキスト・ストリングです。 プロパティー・ファイルを変更する前に、参照用に以下の手順を印刷してください。 各プロパティーのインスタンスごとに、必ず適切な値を入力してください。 wkplc_dbdomain.properties では、ほとんどのプロパティーがドメインごとに繰り返されています。

  2. テキスト・エディターを使用してプロパティー・ファイル wkplc_dbdomain.properties を開き、ご使用の環境に対応するように値を変更します。
    1. dbdomain.DbType の場合は、db2 と入力します。
    2. dbdomain.DbName の場合は、WebSphere Portal ドメイン・データベースの名前を入力します。 DB2 データベース名は、 8 文字以内にする必要があります。
      注:
      • この値は、dbdomain.DbUrl プロパティー内のデータベース・エレメントでもあります。
      • この値は、データベースの TCP-IP 別名です。
    3. dbdomain.DbSchema の場合は、データベース・ドメインのスキーマ名を入力します。
      注: ターゲット・データベース管理システムの文書を参照して、有効なスキーマ名を定義します。 いくつかのデータベース管理システムでは、知っておく必要のあるスキーマ名の制約があります。
    4. dbdomain.DataSourceName の場合は、WebSphere Portal がデータベースとの通信に使用するデータ・ソースの名前を入力します。 以下の予約語を使用しないでください。
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
    5. dbdomain.DbUrl の場合、JDBC を使用してWebSphere Portal データベースにアクセスするときに使用するデータベースの URL を入力します。この値は、データベースで指定された JDBC URL 構文規則に準拠する必要があります。
      注: この値のデータベース・エレメントは、DbName の値と一致する必要があります。
    6. dbdomain.DbUser には、データベース構成ユーザーの ユーザー ID を入力します。
    7. dbdomain.DbPassword には、 データベース構成ユーザーのパスワードを入力します。
    8. dbdomain.DbConfigRoleName には、 データベース構成ユーザーのグループの名前を入力します。データベースの権限は、 個人ではなく、このグループに付与されます。dbdomain.DbUser に指定されているユーザーを、 このグループに割り当てる必要があります。
    9. オプション: dbdomain.DbRuntimeUser の場合は、WebSphere Portal によってランタイムのデータベースへの接続に使用される、データベース・ユーザーのユーザー ID を入力します。この設定に値を指定しない場合は、 ランタイムでデータベースに接続するためにデータベース構成ユーザーが使用されます。
    10. dbdomain.DbRuntimeUser を指定している場合、dbdomain.DbRuntimePassword を、ランタイム・データベース・ユーザーのパスワードとなるように設定する必要があります。
    11. dbdomain.DbRuntimeRoleName には、 データベース・ランタイム・ユーザーの名前を入力します。データベースの権限は、 個人ではなく、このグループに付与されます。dbdomain.DbRuntimeUser に指定されているユーザーを、 このグループに割り当てる必要があります。
    12. オプション: dbdomain.DBA.DbUser には、 データベース作成時の特権アクセス操作のためのデータベース管理者ユーザー ID を 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
    13. オプション: dbdomain.DBA.DbPassword には、 データベース作成時の特権アクセス操作のためのデータベース管理者パスワードを 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
    14. dbdomain.XDbName の場合は、create-database タスクを使用する場合に設定する必要があるデータベースのループバック別名を入力します。
      注: JDBC タイプ 2 ドライバーを使用するローカル・データベースの場合にのみ必要です。
    15. dbdomain.DbNode には、 データベース・ノード名の値を入力します。 この値は、create-database を呼び出す場合に設定します。
      注: ローカル・データベースでのみ必要とされます。
  3. ファイルを保管して閉じる。
  4. wkplc_dbtype.properties ファイルの以下のプロパティーを更新します。
    1. db2.DbDriver の場合は、JDBC ドライバー・クラスの名前を入力します。
    2. db2.DbLibrary の場合は、JDBC ドライバー・クラスを含む .zip、または .jar ファイルのディレクトリーと名前を入力します。
    3. db2.JdbcProviderName の場合は、WebSphere Portal がそのデータベースとの通信に使用する JDBC プロバイダーの名前を入力します。
  5. ファイルを保管して閉じる。
  6. wkplc.properties ファイルの WasPassword 値を 更新します。この値は、ご使用の環境で使用される WebSphere Application Server セキュリティー認証のパスワードです。
  7. ファイルを保管して閉じる。
AIX スタンドアロン: DB2 データベースの作成

IBM WebSphere Portal で必要な DB2 データベースは、 ローカルまたはリモートで作成できます。DB2 データベースをローカルで作成する場合、 データベースは構成タスクを使用して作成するか、手動で作成することができます。 DB2 データベースをリモートで作成する場合、 手動でのみデータベースを作成することができます。

このタスクについて
AIX スタンドアロン: ローカル DB2 データベースの自動作成

このセクションでは、ローカル DB2 のインストール環境を使用する場合の、ConfigEngine タスクを使用してデータベースを作成する方法を説明します。リモート DB2 のインストール環境を使用する場合は、手動でデータベースを作成する必要があります。ConfigEngine タスクを使用してデータベースを作成することはできません。

始める前に
始める前に、以下の前提条件に適合していることを確認してください。
  • データベース管理システム・ソフトウェアがインストールされます。
このタスクについて
以下のステップは、非ルート・ユーザーの場合には create-database タスクを実行できない点を除いて、ルート・ユーザーと非ルート・ユーザーのどちらの場合でも同じです。
手順
  1. wp_profile_root/ConfigEngine ディレクトリーに移動する
  2. データベースを作成するため、以下のコマンドを入力する。
    • ./ConfigEngine.sh create-database -DWasPassword=password
  3. DB2 サーバー・システムのサービス・ファイルを確認する。 DB2 接続ポートおよび割り込みサービス・ポートが指定されていない場合は、ご使用のオペレーティング・システムのポートを指定します。
    1. テキスト・エディターを使用して、 %SYSTEMROOT%¥system32¥drivers¥etc¥services ファイルを開く。
    2. テキスト db2c_db2 50000/tcp を追加する (ここで、db2 はデフォルトのインスタンス)。
      注: 使用するポート番号がまだ使用中ではないことを確認します。50000 が既に使用中である場合は、他のポート番号を選択してください。
AIX スタンドアロン: リモートまたはローカル DB2 データベースの手動作成

リモート・データベースは、WebSphere Portal とは異なるシステム上にあります。 リモート DB2 サーバーを使用する場合は、WebSphere Portal で必要なデータベースを手動で作成する必要があります。

始める前に
これらのデータベースを作成する前に、以下の情報に注意してください。
  • DB2 または IBM DB2 Universal Database Workgroup Server Edition JDBC ドライバー、JCC、タイプ 4 を使用してください。
  • DB2 JDBC タイプ 4 ドライバーを使用する場合、リモート・サーバーに関する説明にのみ従ってください。DB2 クライアント・ソフトウェアをインストールしたり、DB2 クライアントに関連したステップを実行したりする必要はありません。
  • リモートの DB2 データベースを使用する場合は、リモートの DB2 サーバーから WebSphere Portal サーバーにタイプ 4 JAR ファイル (db2jcc.jar および db2jcc_license_cu.jar) をコピーする必要があります。標準的な場所は、db2_home/java ディレクトリーです。ご使用のローカル・マシン上のタイプ 4 JAR ファイルの場所を、参照用に記録します。
  • DB2 クライアント・ソフトウェアは、リモートの DB2 サーバー・インスタンス (例えば db2inst1) に接続するように、正しく構成する必要があります。
  • これらの手順では、リモート DB2 サーバーおよび DB2 クライアントがすでにインストールされ、実行されていることを前提としています。
このタスクについて
データベースを作成するには、十分なデータベース特権 (SYSADM または少なくとも SYSCTRL) を持つ DB2 システム管理者である必要があります。
手順
  1. DB2 インスタンスのシステム権限でログインする。例えば、DB2 インスタンス所有者として db2inst1 にログインできます。
  2. コマンド・プロンプトを開き、DB2 インスタンスの db2profile を実行して、DB2 コマンド環境を初期化する。例えば、. /home/db2inst1/sqllib/db2profile を実行します。ここで、db2inst1 は、ご使用の DB2 インスタンスの DB2 インスタンス所有者です。

    プロンプトが、ご使用のオペレーティング・システムのシェル・プロンプト (例えば $) に変更されます。このモードでは、各コマンドの先頭に db2 と入力し、 コマンド全体を二重引用符 ("") で囲む必要があります。 以下の例は、二重引用符の使用方法を示しています。これは、ユーザーが実行する実際のコマンドではありません。

    db2 "CREATE REGULAR TABLESPACE SMS PAGESIZE 4 K MANAGED BY SYSTEM USING ('sms') BUFFERPOOL SMSPOOL"
    注: コマンド行プロセッサー (CLP) を使用する場合、詳しくは、DB2 の資料を参照してください。コマンド・プロンプトは db2=> です。このモードでは、 コマンドを入力するときに、プレフィックス db2 も二重引用符も必要ありません。 ただし、以下のステップでは、CLP を使用せず、ご使用のオペレーティング・システムのシェル・プロンプト (例えば、$) からコマンドを入力する場合を想定しています。
  3. DB2 サーバー・システムで以下のコマンドを実行して、DB2 データベース・インスタンスを構成する。
    環境 説明
    DB2
    db2set DB2COMM=TCPIP
    db2set DB2_EVALUNCOMMITTED=YES
    db2set DB2_INLIST_TO_NLJN=YES
    db2 "UPDATE DBM CFG USING query_heap_sz 32768"
    db2 "UPDATE DBM CFG USING sheapthres 0"
    
  4. (重要) このステップを完了しないと、データベース転送が失敗します。DB2 サーバー・システムで以下のコマンドを実行して、必要なデータベースを作成する。
    注:
    • dbname は、データベースの実際の名前に置き換えてください。 コマンドを実行し、そのたびに dbname を、release、community、customization、Java Content Repository、Feedback、および Likeminds の実際の値に置き換えてください。データベースごとに 1 回、合計 6 回、コマンドを実行する必要があります。
      要確認: DB2 データベース名は、8 文字を超えてはなりません。したがって、次のデータベース名を使用することを検討してください。releasecommuncustomjcrdbfdbkdb、および lmdb
    db2 "CREATE DB dbname using codeset UTF-8 territory us PAGESIZE 8192"
    db2 "UPDATE DB CFG FOR dbname USING applheapsz 4096"
    db2 "UPDATE DB CFG FOR dbname USING app_ctl_heap_sz 1024"
    db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
    db2 "UPDATE DB CFG FOR dbname USING dbheap 2400"
    db2 "UPDATE DB CFG FOR dbname USING locklist 1000"
    db2 "UPDATE DB CFG FOR dbname USING logfilsiz 4000"
    db2 "UPDATE DB CFG FOR dbname USING logprimary 12"
    db2 "UPDATE DB CFG FOR dbname USING logsecond 20"
    db2 "UPDATE DB CFG FOR dbname USING logbufsz 32"
    db2 "UPDATE DB CFG FOR dbname USING avg_appls 5"
    db2 "UPDATE DB CFG FOR dbname USING locktimeout 30"
    db2 "UPDATE DB CFG FOR dbname using AUTO_MAINT off"
  5. 以下を実行します。
    1. DB2 サーバー・システムで、以下のコマンドを実行する。このステップが必要なのは、IBM Java Content Repository データベース (jcrdb) の場合だけです。
      • jcrdb は、ユーザー・データおよびオブジェクトの保管に使用するデータベースの名前です。
      • jcr は、jcrdb の jcr ユーザーです。
        注: この値は、管理権限を持つ任意の ID に置き換えてもかまいません。
      • dbpassword は、jcrdb の jcr ユーザーのパスワードです。
      db2 "CONNECT TO jcrdb USER jcr USING dbpassword"
      db2 "CREATE BUFFERPOOL ICMLSFREQBP4 SIZE 1000 PAGESIZE 4 K"
      db2 "CREATE BUFFERPOOL ICMLSVOLATILEBP4 SIZE 16000 PAGESIZE 4 K"
      db2 "CREATE BUFFERPOOL ICMLSMAINBP32 SIZE 16000 PAGESIZE 32 K"
      db2 "CREATE BUFFERPOOL CMBMAIN4 SIZE 1000 PAGESIZE 4 K"
      db2 "CREATE REGULAR TABLESPACE ICMLFQ32 PAGESIZE 32 K MANAGED BY SYSTEM USING ('ICMLFQ32') BUFFERPOOL ICMLSMAINBP32"
      db2 "CREATE REGULAR TABLESPACE ICMLNF32 PAGESIZE 32 K MANAGED BY SYSTEM USING ('ICMLNF32') BUFFERPOOL ICMLSMAINBP32"
      db2 "CREATE REGULAR TABLESPACE ICMVFQ04 PAGESIZE 4 K MANAGED BY SYSTEM USING ('ICMVFQ04') BUFFERPOOL ICMLSVOLATILEBP4"
      db2 "CREATE REGULAR TABLESPACE ICMSFQ04 PAGESIZE 4 K MANAGED BY SYSTEM USING ('ICMSFQ04') BUFFERPOOL ICMLSFREQBP4"
      db2 "CREATE REGULAR TABLESPACE CMBINV04 PAGESIZE 4 K MANAGED BY SYSTEM USING ('CMBINV04') BUFFERPOOL CMBMAIN4"
      db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE32 PAGESIZE 32 K MANAGED BY SYSTEM USING ('icmlssystspace32') BUFFERPOOL ICMLSMAINBP32"
      db2 "CREATE SYSTEM TEMPORARY TABLESPACE ICMLSSYSTSPACE4 PAGESIZE 4 K MANAGED BY SYSTEM USING ('icmlssystspace4') BUFFERPOOL ICMLSVOLATILEBP4"
      db2 "CREATE USER TEMPORARY TABLESPACE ICMLSUSRTSPACE4 PAGESIZE 4 K MANAGED BY SYSTEM USING ('icmlsusrtspace4') BUFFERPOOL ICMLSVOLATILEBP4"
      db2 "UPDATE DB CFG FOR jcrdb USING DFT_QUERYOPT 2"
      db2 "UPDATE DB CFG FOR jcrdb USING PCKCACHESZ 16384"
      db2 "DISCONNECT jcrdb"
      db2 "TERMINATE"
    2. JDBC タイプ 2 接続の場合のみ: DB2 クライアントで、テキスト・エディターを使用して、/etc/services ファイルを開く。DB2 connection service port が指定されていない場合は、次のテキストを加えてリモート DB2 インスタンスのポートを指定します。
      DB2_db2inst1 port1/tcp # DB2 connection service port
      ここで、db2inst1 は、システム上の DB2 インスタンスの名前です。また、port1 は、ご使用の DB2 サーバー・インストール済み環境で DB2 接続サービスに割り当てられた実際のポート番号です。DB2 Client システムWebSphere Portal サーバーの接続サービス・ポートは、DB2 サーバーの接続サービス・ポートと一致している必要があります。 ポートの番号は一致していなければなりませんが、ポートの名前は一致していなくてもかまいません。
    3. JDBC タイプ 2 接続の場合のみ: DB2 サーバー・システムで、db2 "UPDATE DBM CFG USING svcename svce_name" というコマンドを入力して、正しいサービス名を設定する。ここで、svce_name は、上のステップで指定した接続サービス・ポート名を表します。
    4. JDBC タイプ 2 接続の場合のみ: DB2 クライアントで、db2set コマンド db2set DB2COMM=tcpip を使用して DB2COMM を TCP/IP に設定する。
    5. JDBC タイプ 2 接続の場合のみ: DB2 Connect のリモート・データベース・サーバーの IP アドレスで TCP/IP ノードをカタログに登録する: db2 "catalog tcpip node remote_db_node_alias remote database_server_node server connection_service_port" ここで、
      • remote_db_node_alias は、WebSphere Application Server ノード名として定義しているデータベース・サーバーの別名を表します。 別名に使用できる文字数は 1 から 8 文字です。
      • database_server_node は、データベース・サーバー・システムの完全修飾ホスト名です。
      • connection_service_port は、データベース・サーバー・システム上の /etc/services ファイルに構成された DB2 接続サービス・ポートの名前です。
    6. JDBC タイプ 2 接続の場合のみ、DB2 Connect の WebSphere Portal データベースをカタログに登録する。ここで、
      • remote_db_name_domain は、各ドメインのサーバー・システム上でのデータベースのカタログ名を表します。
      • domain_alias_name は、定義しているデータベース別名を表します。
      • remote_db_node_alias は、前のステップで TCP/IP ノードをカタログした際に使用した名前です。
      各データベースの別名は、実データベース名と異なっている必要があり、最大 8 文字で構成することができます。
      db2 "catalog db remote_db_name_release as release_alias_name at node remote_db_node_alias"
      db2 "catalog db remote_db_name_community as comm_alias_name at node remote_db_node_alias"
      db2 "catalog db remote_db_name_customization as cust_alias_name at node remote_db_node_alias"
      
      db2 "catalog db remote_db_name_fdbkdb as fdbkdb_alias_name at node remote_db_node_alias"
      db2 "catalog db remote_db_name_lmdb as lmdb_alias_name at node remote_db_node_alias"
      db2 "catalog db remote_db_name_jcrdb as jcrdb_alias_name at node remote_db_node_alias"
      
    7. JDBC タイプ 2 接続の場合のみ: db2 "terminate" と入力して、DB2 Connect からログアウトする。
    8. JDBC タイプ 2 接続の場合のみ、DB2 Connect において、DB2 コマンド・ウィンドウで db2 "connect to alias_name user username using password" というコマンドを実行して、リモート接続をテストする。ここで、alias_name は上のステップで定義した別名、username はデータベース・ユーザー、password はこのデータベース・ユーザーに割り当てられたパスワードを表します。
AIX スタンドアロン: DB2 の自動または手動セットアップ

DB2 データベースを作成したら、データベースを構成タスクを使用して自動的にセットアップするか、手動でセットアップします。DB2 データベースの作成後に選択するセットアップ方法は、DB2 データベースの作成が、ローカルあるいはリモートのいずれで行われたかに左右されません。

このタスクについて
AIX スタンドアロン: DB2 の自動セットアップ

このセクションでは、ConfigEngine タスクを使用してデータベースを自動的にセットアップする手順を示します。データベースを自動的にセットアップする代わりに、手動でユーザーを作成し、特権を付与することも可能です。また、ConfigEngine タスクでは実行されない、オプションの構成タスクを実行することもできます。

このタスクについて
AIX スタンドアロン: DB2 データベースを自動セットアップするためのタスクの実行

このトピックでは、ConfigEngine タスクを使用してデータベースを自動的にセットアップする手順を示します。データベースを自動的にセットアップする代わりに、手動でユーザーを作成し、特権を付与することも可能です。

始める前に
このトピックで構成タスクを実行する前に、DB2 データベースを 作成する必要があります。
手順
  1. wp_profile_root/ConfigEngine ディレクトリーに移動する
  2. データベース・ユーザーを作成するため、以下のコマンドを入力する。
    注: タスク setup-database は、最小限のデータベース特権を データベース構成ユーザーおよびランタイム・データベース・ユーザーに割り当てます。
    • ./ConfigEngine.sh setup-database -DWasPassword=password
    注: このタスクにより、必要なユーザー、アクセス権、およびテーブル・スペースが自動的に作成されます。
AIX スタンドアロン: DB2 の手動セットアップ

データベースを自動的にセットアップする代わりに、 手動で DB2 データベースを構成して、 ユーザーを作成し、特権を付与することも可能です。 ConfigEngine タスクを実行してデータベースを自動的に構成した場合は、 ユーザー、特権、またはテーブル・スペースを作成するための手動タスクを実行する必要はありません。 ただし、ConfigEngine タスクを実行した際に自動的に提供されない項目について、 手動による追加の構成を実行することができます。例えば、カスタム・テーブル・スペースの割り当ては、 自動化された ConfigEngine タスクでは扱われないオプション・タスクです。

AIX スタンドアロン: DB2 データベース・スキーマの作成

データベース・スキーマを作成する場合、 テンプレート SQL スクリプトのコピーを作成し、そのコピーを編集して、 データベース・スキーマを手動で作成することができます。テンプレート SQL スクリプトは、実行可能スクリプトを作成する際にガイドとして使用します。 また、このスクリプトには無効な SQL 構文が含まれています。

始める前に
始める前に: DB2 のインストールを完了しておく必要があります。
このタスクについて

すべてのデータベースに、オペレーティング・システムおよび DB2 インストールに対する管理権限を持つ 1 つのユーザーを使用します。 このユーザーは、DB2 インストール・プログラムによって自動的に作成されるデータベース管理ユーザーにすることもできます。 このユーザーは、データベース表の作成とデータベース転送の実行という構成タスクのために使用するデータベース構成ユーザーです。 WebSphere Portal でデータベースの作成もする場合は、デ ータベース・ユーザーに SYSADM 権限を与える必要があります。 既存の DB2 管理者 ID を使用しない場合は、 管理者 ID を手動で作成する必要があります。

一般的なユーザー名は db2inst1 ですが、このユーザーに管理アクセス権があり、以下に示す制限に従っている限り、任意のユーザー名を割り当てることができます。 作成後にユーザー名を変更しないでください。

ユーザー名およびグループ名は、 データベース管理システムのソフトウェア要件と WebSphere Portal 要件の両方に準拠している必要があります。ユーザー名の制限は以下のとおりです。
  • ユーザー名に使用できる文字数は 1 から 8 文字です。
  • グループ名およびインスタンス名に使用できる文字数は 1 から 8 文字。
  • 名前に、以下のものは使用できません。
    users
    admins
    guests
    public
    local
  • 名前は、以下の語で始めることはできません。
    IBM
    SQL
    SYS
  • 名前にアクセント付き文字を含むことはできません。
  • 実際の実行時環境と同じ設定になっている環境でユーザーを作成してください。 例えば、トルコ語環境でユーザーを使用するつもりである場合、そのユーザーを英語環境で作成するのは避けてください。

SQL スクリプト・テンプレートを参照する場合は、以下の場所を参照してください。

表 32. データベース・ドメイン別 SQL スクリプト・テンプレートのリスト
データベース・ドメイン テンプレートの場所
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createSchema.sql
Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createSchema.sql
Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createSchema.sql
JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createSchema.sql
Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createSchema.sql
Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createSchema.sql
AIX スタンドアロン: DB2 データベース・ユーザーへの特権の付与

構成データベース・ユーザーおよびランタイム・データベース・ユーザーには、スキーマ所有者かどうかに応じて、異なる特権セットが付与されます。SQL スクリプトのコピーを作成し、そのコピーを編集して、構成データベース・ユーザーおよびランタイム・データベース・ユーザーに手動でアクセス権を付与することができます。

構成データベース・ユーザーに必要な特権

構成データベース・ユーザーが スキーマの所有者である場合、domain.DbUser プロパティーは domain.DbSchema プロパティーと同じ値が割り当てられ、 各データベース・ドメインで構成ユーザーのために役割が作成されます。 この役割は、setup-database 構成タスクを実行すると自動的に作成されて、 割り当てられます。この役割を自動的に作成して割り当てる代わりに、 IBM WebSphere Portal のインストール・ディレクトリー にある SQL スクリプト・テンプレートのコピーを作成して、 それを、アクセス権を手動で付与するための実行可能スクリプトを作成するための ガイドとして使用することができます。 これらの読み取り専用テンプレートを変更して、 無効の SQL 構文を含めてはなりません。特権を手動で付与するには、これらのファイルの独自のバージョンを作成して、 実行可能スクリプトを作成する必要があります。

スキーマの所有者である構成データベース・ユーザーに付与される特定のアクセス権について詳しくは、SQL スクリプト・テンプレートの以下の場所を参照してください。

表 33. スキーマの所有者である構成データベース・ユーザーに付与された特定のアクセス権を参照するための、データベース・ドメイン別 SQL スクリプト・テンプレートの場所
データベース・ドメイン テンプレートの場所
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql

Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql

Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql

JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql

Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForSameSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql

Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForSameSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql

スキーマの所有者ではない構成データベース・ユーザーについては、 SQL スクリプト・テンプレートの以下の場所を参照してください。

表 34. スキーマの所有者でない構成データベース・ユーザー用のデータベース・ドメイン別 SQL スクリプト・テンプレートの場所
データベース・ドメイン テンプレートの場所
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createConfigRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToConfigUser.sql

Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createConfigRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToConfigUser.sql

Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createConfigRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToConfigUser.sql

JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createConfigRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToConfigUser.sql

Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createConfigRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToConfigUser.sql

Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createConfigRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToConfigUser.sql

ランタイム・データベース・ユーザーに必要な特権

ランタイム・データベース・ユーザーが スキーマの所有者である場合、domain.DbUser プロパティーは domain.DbRuntimeUser および domain.DbSchema プロパティーと同じ値が割り当てられます。 ランタイム・データベース・ユーザーは通常、データの照会および操作に使用する表を作成することはなく、 デフォルトで、これらの表にアクセスできません。 これらの表で作業するために、ランタイム・データベース・ユーザーに最小限の特権を付与するには、 個々のオブジェクトに対してアクセス権が提供される必要があります。 各データベース・ドメインでランタイム・データベース・ユーザーに対して役割が 作成されます。これらの役割は、データベースの転送前に setup-database 構成タスクを実行したときに自動的に作成および割り当てられ、その後、データベース転送後に grant-runtime-db-user-privileges 構成タスクを実行します。 これらの構成タスクを実行する前は、 ランタイム・データベース・ユーザーは、データベースにアクセスして 構成の妥当性検査を実行することしかできません。この役割を自動的に作成して割り当てる代わりに、 IBM WebSphere Portal のインストール・ディレクトリー にある SQL スクリプト・テンプレートのコピーを作成して、 それを、アクセス権を手動で付与するための実行可能スクリプトを作成するための ガイドとして使用することができます。 これらの読み取り専用テンプレートを変更して、 無効の SQL 構文を含めてはなりません。特権を手動で付与するには、これらのファイルの独自のバージョンを作成して、 実行可能スクリプトを作成する必要があります。

スキーマの所有者であるランタイム・データベース・ユーザーに 付与される特定のアクセス権について詳しくは、SQL スクリプト・テンプレートの以下の場所を参照してください。

表 35. スキーマの所有者であるランタイム・データベース・ユーザーに付与された特定のアクセス権を参照するための、データベース・ドメイン別 SQL スクリプト・テンプレートの場所
データベース・ドメイン テンプレートの場所
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createInitialRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/grantRoleToRuntimeUser.sql

Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createInitialRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/grantRoleToRuntimeUser.sql

Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createInitialRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/grantRoleToRuntimeUser.sql

JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForSameSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantExtendedPermissionsToRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql

Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createInitialRuntimeRole.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForSameSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/grantRoleToRuntimeUser.sql

Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createInitialRuntimeRole.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForSameSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/grantRoleToRuntimeUser.sql

スキーマの所有者ではないランタイム・データベース・ユーザーに 付与される特定のアクセス権について詳しくは、SQL スクリプト・テンプレートの以下の場所を参照してください。

表 36. スキーマの所有者でないランタイム・データベース・ユーザーに付与された特定のアクセス権を参照するための、データベース・ドメイン別 SQL スクリプト・テンプレートの場所
データベース・ドメイン テンプレートの場所
Release PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/release/createRuntimeRoleForDifferentSchema.sql

Community PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/community/createRuntimeRoleForDifferentSchema.sql

Customization PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/customization/createRuntimeRoleForDifferentSchema.sql

JCR PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createInitialRuntimeRole.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/base/wp.db.impl/config/templates/setupdb/db2/jcr/grantExtendedPermissionsToRuntimeRole.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/jcr/grantRoleToRuntimeUser.sql

Feedback PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/feedback/createRuntimeRoleForDifferentSchema.sql

Likeminds PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql

PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/db2/likeminds/createRuntimeRoleForDifferentSchema.sql

AIX スタンドアロン: カスタム DB2 テーブル・スペースの割り当て

WebSphere Portal のリポジトリーは、デフォルト・テーブル・スペースで作成される多くのテーブルとインデックスで構成されています。リポジトリーのオブジェクトとして既存のテーブル・スペースのセットを使用する場合は、ターゲット・データベース・システムへのデータベース転送を実行するときに指定します。

始める前に
始める前に
  • データベース転送を実行するには、それより前にカスタム・テーブル・スペースが存在している必要があります。
  • 5 つの JCR テーブル・スペース (ICMLFQ32、ICMLNF32、ICMVFQ04、ICMSFQ04、CMBINV04) は、カスタマイズできません。
  • WebSphere Portal で使用されるテーブル・スペースのページ・サイズは 8192 バイトにする必要があります。
  • テーブル・スペースの作成について詳しくは、データベースの資料を参照してください。
このタスクについて

カスタム・テーブル・スペースを割り当てる場合は、それぞれを明示的に割り当てる必要があります。デフォルト・テーブル・スペースは、データベース・オブジェクトを収容するために使用できますが、デフォルト・テーブル・スペースの名前は対応するマッピング・ファイルで指定する必要があります。これは、1 回のデータベース転送で転送されるすべてのデータベース・ドメインに適用されます。

カスタム・テーブル・スペースの割り当てを構成するには、以下の手順を実行します。

手順
  1. カスタム・テーブル・スペースの名前を決定する。
  2. データベース・テーブルごとにテーブル・スペースとインデックス・スペースのプロパティー・ペアを指定するマッピング・ファイル wp_profile_root /PortalServer/config/tablespaces/dbdomain.space_mapping.propertiesを開く。
    • dbdomain.table_name.tablespace
    • dbdomain.table_name.index_name.indexspace
    ファイル名と、テーブル・スペース・プロパティーおよびインデックス・スペース・プロパティーとのペアごとに、dbdomain の値は以下に示す値のいずれかになります。
    • release
    • community
    • customization
    • jcr
    • feedback
    • likeminds
  3. マッピング・ファイルの各エントリーにテーブル・スペースを割り当てる。テーブル・スペース名の前には、キーワード IN とスペース 1 つを挿入する必要があります。例: community.COMP_INST.tablespace=IN COMM8KSPACE
    転送するドメインごとにこの手順を繰り返します。
  4. dbdomain.space_mapping.properties を保管して閉じる。
  5. コマンド・プロンプトで、データベース転送を開始するときに -DuseCustomTablespaceMapping=true オプションを指定する。 以下に例を示します。
    • Windows: ConfigEngine.bat database-transfer -DuseCustomTablespaceMapping=true
    • UNIX: ./ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true
    • i: ConfigEngine.sh database-transfer -DuseCustomTablespaceMapping=true
AIX スタンドアロン: JCR 照合サポートの構成

ここでは、ご使用の DB2 データベースと連動させる JCR 照合をセットアップするステップを示します。ユーザーの言語ロケールが DB2 データベース内でネイティブに正しく照合されないとき、および言語ロケールの正しい順序が重要なときには、JCR 照合が推奨されます。

このタスクについて
手順
  1. WebSphere Portal サーバーを停止する。 手順については、「サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止」を参照してください。
  2. WebSphere Portal サーバーから DB2 サーバー上の一時ディレクトリーに以下のファイルをコピーする。
    PortalServer/jcr/wp.content.repository.install/lib/wp.content.repository.install.jar
    wp_profile/PortalServer/jcr/config/registerUDFTemplate.sql
  3. JCR ドメインが配置されているデータベースでの照合をセットアップする。
    1. db2_instance_owner_home/sqllib/function ディレクトリーに移動する。
    2. 次のコマンドを実行する。

      db2home/sqllib/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar icm/CollationUDF.class

    3. 前のステップでファイルをコピーした一時ディレクトリーに移動する。
    4. registerCollationUDFTemplate.sql ファイルを開き、すべての SCHEMA 参照を JCR スキーマに変更する (例えば、JCR)。

      SCHEMA の値セットは、jcr.DbSchema プロパティーの値セットと一致するようにしてください。データベース・プロパティーを変更する際は、構成ファイル wkplc_dbdomain.propertiesjcr.DbSchema を指定します。詳しくは、『データベース・プロパティーの変更』を 参照してください。

    5. 以下のコマンドを実行して、JCR データベースに接続する。db2 connect to jcrdb user user_ID using password
    6. 以下のコマンドを使用して、スクリプトを実行する。

      db2 -tvf temporary location/registerCollationUDFTemplate.sql

    7. JCR データベースから切断する。
    8. DB2 インスタンスを再始動する。
  4. UDF が正常に登録されていることを確認する。
    1. db2instanceID としてログインする。
      1. DB2 端末ウィンドウを開く。
      2. 以下のコマンドを実行する。db2 connect to JCRDB user user_ID using password WebSphere Portal JCR データ・ソースのユーザー ID およびパスワードを使用して、 データベース・ランタイム・ユーザーとして JCR データベースに接続する必要があります。
      コマンドが正常に完了すると、以下のように UDF が正しく登録されます。values schema.sortkeyj('abc','en')
  5. wp_profile_root¥PortalServer¥jcr¥lib¥com¥ibm¥icm ディレクトリーにある icm.properties ファイルを編集する。ファイルの末尾に以下のセクションを追加します。
    		# Enable/Disable collation support for all DB2 platforms
    		# Disabled by default
    		jcr.query.collation.db2.enabled = true
    
    		# Database specific collation mappings
    		# These mappings apply map a Java locale name into a collation name
    		# supported by the underlying database.
    		# Example mappings for DB2 platform
    
    		# English
    		jcr.query.collation.en = en
    	
    		# Swedish
    		jcr.query.collation.sv = sv
    
    		jcr.query.collation.zh = zh
    		jcr.query.collation.de = de
    		jcr.query.collation.da = da
    		jcr.query.collation.hu = hu
    		jcr.query.collation.jp = jp
  6. WebSphere Portal サーバーを開始する。 手順については、「サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止」を参照してください。
AIX スタンドアロン: DB2 を使用するための WebSphere Portal の構成

このセクションでは、デフォルトのデータベースから Oracle データベースに、手動でデータを転送する方法について説明します。WP および Java Content Repository データベースを DB2 に転送する場合は、以下のステップを実行します。ここで説明する手動のデータベース転送手順の代わりに、構成ウィザードを使用してデータベース転送タスクを実行することもできます。

始める前に

始める前に
以下の前提条件に適合していることを確認します。

  • サポートされるデータベース・ソフトウェアがインストール済み。
  • データベースとユーザーがセットアップ済み。
このタスクについて
ヒント:
  • これらのタスクを root 以外のユーザーとして実行するには、まず、chown -R non-root_user WebSphereDir タスクを実行する必要があります。
  • Oracle または Oracle RAC から転送する場合、open_cursors 設定は、デフォルトでは 1500 に設定されています。 ただし、Java Content Repository スキーマのテーブル数に基づいて、この値を増やす必要が生じる場合があります。
手順
  1. タイプ 2 の接続を実行している場合は、データを転送する前に、WebSphere Portal がインストールされているローカル・システムにある db2cli.ini ファイルを編集します。
    重要: 以下のステップを実行しないと、データベース転送はタスク action-process-constraints において無応答になります。
    1. ファイル /home/db2inst1/sqllib/cfg/db2cli.ini を見つけます。
    2. ファイルの末尾に以下の行を追加します。
      Editing db2cli.ini:
      • ファイル内に [COMMON] というセクションが既に存在する場合は、以下の行を追加することにより、そのセクションを拡張します。 まだない場合は、[COMMON] セクションをファイルに追加します。
      • ReturnAliases=0 の後は、 空白行のままにしておいてください。
      [COMMON]
      DYNAMIC=1
      ReturnAliases=0
  2. WebSphere Portal の複数インスタンスをインストールする場合にのみ、 このステップを実行する。 データベースの最大数 MAX_NETBIOS_CONNECTIONS を変更して、デフォルトで構成されているデータベースの数を増やします。 例えば、データベースのプロンプトで、 set client MAX_NETBIOS_CONNECTIONS 254 というコマンドを入力します。 最大数が増えると成功のメッセージが表示されます。
  3. コマンド・プロンプトを開き、ディレクトリー wp_profile_root/ConfigEngine に 移動する。
  4. JDBC タイプ 2 ドライバーを使用している場合のみ、DB2 のインストール時に作成した DB2 ユーザー・プロファイルを、次のコマンドを使用して管理ユーザーにエクスポートする。 このコマンドにより、DB2 ユーザーのプロファイルが管理ユーザーにエクスポートされ、管理ユーザーが DB2 ユーティリティーにアクセスできるようになります。
    . /home/db2inst1/sqllib/db2profile
    ここで、db2inst1 はデータベース・インスタンスを表します。
    注: データベース・タスクを実行する前とセキュリティーを使用可能にする前に、このステップを実行する必要があります。
  5. ./ConfigEngine.sh validate-database -DWasPassword=password コマンドを入力して、構成プロパティーを検証する。
    ヒント: 検証するドメインを指定するには、上記の検証タスクに -DTransferDomainList パラメーターを追加します。例えば、-DTransferDomainList=jcr とします。 すべてのドメインを検証する場合、コマンド行でこのパラメーターを指定する必要はありません。
  6. 前のステップと同じコマンド・プロンプトから、ディレクトリー wp_profile_root/bin に移動する。
  7. server1 および WebSphere_Portal サーバーの両方を停止する。
    • ./stopServer.sh server1 -username admin_userid -password admin_password
    • ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
  8. 以下の手順でデータベースを転送する。
    1. wp_profile_root/ConfigEngine ディレクトリーに移動する。
    2. 以下のコマンドを入力する。
      ./ConfigEngine.sh database-transfer -DWasPassword=password 
      注:
      • 特定のデータベース・ドメインを転送対象に選択するには、コマンドで指定する -DTransferDomainList に、転送するドメインのみが含まれるように変更します。例えば、JCR ドメインのみを転送する場合は、コマンド ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=password を入力します。
      • ApacheDerby にデータを長い間保管している場合、OutOfMemory 例外を出してデータベース転送が失敗する可能性があります。データベース転送が失敗する場合は、このステップで次のプロパティーをコマンドに追加してください。ConfigEngine.bat database-transfer -DDbtJavaMaxMemory=1536M -DWasPassword=password
    3. このタスクを実行すると、タスクが正常に実行されたことが確認可能なメッセージが、以下のログ・ファイルに追加されます。wp_profile_root/ConfigEngine/log/ConfigTrace.log 構成が失敗した場合は、wkplc.propertieswkplc_dbdomain.propertieswkplc_dbtype.properties の各ファイルの値を確認してから、このステップを繰り返してください。
  9. オプション: dbdomain.DbRuntimeUser パラメーターにランタイム・データベース・ユーザーを指定した場合は、そのユーザーに十分なデータベース・ユーザー特権を与える必要があります。データベース・ユーザーに特権を付与するには、以下の手動のステップ、またはコマンド行のステップを選択します。
    1. 手動でデータベース・ユーザーに特権を付与するには、以下のステップを実行します。
      1. 該当するテンプレート・ファイルを作業ディレクトリーにコピーする。以下のテンプレート・ファイルのいずれか 1 つを選択します。
        • createRuntimeRoleForDifferentSchema.sql - データベース・ユーザーの名前とスキーマの名前が同じでない場合。