test

Sun Java System Portal Server 7.1 配備計画ガイド

第 6 章 配備設計の実装

ソリューションライフサイクルの実装段階では、配備設計の段階で作成された仕様および計画をもとに配備アーキテクチャーを構築およびテストし、最終的には配備を本稼動環境に移行します。

実装は本ガイドの適用範囲外ですが、この章で、配備プロトタイプの監視とチューニングの方法について説明します。

この章で説明する内容は次のとおりです。

配備設計の実装について

配備アーキテクチャーが承認され、実装仕様および計画が完成すると、ソリューションライフサイクルの実装段階に入ります。実装は、一連の複雑なプロセスおよび手順から成り、成功を確実にするには入念な計画が必要になります。

実装には次のタスクが含まれます。

実装の詳細は、本ガイドの適用範囲外です。ただし、次のセクションで、いくつかのタスクについて概説します。

ポータルの文書化

ポータルの機能の包括的な文書は、システムをサポートしやすくする重要な手段です。サポート可能なソリューションを作成するために文書化する必要がある領域を次に示します。

運用書には、障害追跡の方法や配備のライフサイクルが要約されています。プロジェクトのトレーニングおよび知識の移譲段階でこのブックを利用できるようにします。

ヒント –

配備プロジェクトの終わりまで待たずに文書化を開始してください。ポータルの文書化は、配備過程全体を通して行う必要がある活動です。

ポータルのプロトタイプの開発

Procedureポータルのプロトタイプを開発する

  1. プロセッサ、メモリー、ネットワーク、およびディスクの明らかな障害を識別して取り除きます。

  2. 制御された環境をセットアップして、同一条件での動作変動が 10 パーセント未満に定義されるエラーの許容範囲を最小限に抑えます。

    開始データの測定基準が分かれば、サンプル収集動作間のデータパフォーマンスの変動を測定できます。測定値は適切な長さの時間で収集し、これらのテストの結果を捕捉して評価できるようにします。

    Portal Server マシンとは別に、負荷シミュレーションデータを収集する専用マシンの使用を計画します。専用マシンは、パフォーマンス問題の原因を突き止めるのに役立ちます。

  3. 配備のパフォーマンスの基準を定義してから、プロジェクトの複雑な部分を追加していきます。

  4. この最初のベンチマークを使用して、短期および長期的に組織がサポートするトランザクションの量を定義します。

    現在の物理的なインフラストラクチャーが、定義したトランザクションの量の要件をサポート可能であるかどうかを確認します。

    ポータルに対するアクティビティーが増えるにつれ、最初に限度に達するサービスを特定します。これにより、上限までの余裕が示され、また強化すべきところが特定されます。

  5. ポータルの提供者、管理者、および開発者が同意する予想生産環境をできるだけ正確にシミュレーションする、プロトタイプワークロードを作成して微調整します。

  6. プロトタイプを検証するためにトラフィックを定期的に測定および監視します。

    CPU の使用率を一定の期間追跡します。通常、負荷は急に上昇し、上昇が発生する前に対策を講じるためには利用可能な機能の慎重な評価が必要です。

    ほとんどの組織はポータルサイトが「スティッキー」な性質を持つことを認識しています。つまり、ユーザーのコミュニティーのサイズが固定されていても、ユーザーがそのサイトに慣れてくると、サイトの使用率が時間の経過とともに増加することを意味します。また、ユーザーのコミュニティーのサイズが時間の経過とともに増加する場合も、成功しているポータルサイトでは短期間に CPU 要件が高まる場合があります。

    ポータルサーバーの CPU の使用率を監視する場合、負荷のピーク時における平均 Web ページ待ち時間を確認し、それが平均の待ち時間とどれだけ異なるかを確認します。

    ピーク時の負荷は、短期間ではありますが、平均の負荷の 4 〜 8 倍の負荷であると予測します。

  7. モデルを使用して、長期のシナリオを計画します。プロトタイプを使用すると、今後数年の総合的な成長予測に対応するために、配備をどれだけ大幅に変更する必要があるかを理解できます。

  8. エラーロギングレベルを MESSAGE ではなく ERROR に保ちます。MESSAGE エラーレベルは冗長であり、ファイルシステムのディスク領域がすぐに不足する原因になります。ERROR レベルは、すべてのエラー状態と例外をログに記録します。

  9. ポートレットのようなカスタマイズされたポータルアプリケーションを監視します。

  10. 次の領域を監視します。

    • ポータルデスクトップ

    • チャネルレンダリング時間

    • Sun JavaTM System Access Manager

    • Sun Java System Directory Server

    • Sun Java System 仮想マシン

    • Web コンテナ

    次に、ポータルのパフォーマンスにおける可変要素の観点から問題について説明し、ポータルの効率を判断する際の指針を示します。

Access Manager のキャッシュとセッション

ポータルシステムのパフォーマンスは、Access Manager キャッシュのキャッシュヒット率の影響をかなり受けます。このキャッシュは高度にチューニング可能ですが、このキャッシュが使用するメモリーとヒープの残りの利用できるメモリーのどちらかを選択する必要があります。

amSDKStats ログを有効にして、サーバー上のアクティブなセッションの数と Directory Server キャッシュの効率を監視できます。それらのログは、デフォルトで /var/opt/SUNWam/stats ディレクトリにあります。ロギング間隔を設定するには、com.iplanet.am.stats.interval パラメータを使用します。5 秒未満の値を使用しないでください。30 〜 60 秒の値を使用すると、パフォーマンスに影響を与えずに良い結果が得られます。

com.iplanet.services.stats.directory パラメータを使用して、ファイルまたは Portal Server 管理コンソールのどちらかのログの場所を指定したり、ログを無効にしたりします。変更を有効にするには、サーバーを再起動する必要があります。ログは、システムがアクティビティーを検出するまで、作成されません。

注 –

複数の Web コンテナインスタンスが、同じファイルにログを書き込みます。

amSDKStats ファイルに表示されるキャッシュヒット率は、サーバーが起動されてからの内部の値と全体的な値の両方を示します。ユーザーがログインすると、ユーザーのセッション情報は、無期限あるいはキャッシュが一杯になるまでキャッシュに残ります。キャッシュが一杯になると、もっとも古いエントリが先に削除されます。サーバーがユーザーのエントリを削除する必要がない場合は、数日後にログインするときに、ユーザーの情報がキャッシュから取得されることがあります。ヒット率が高いと、パフォーマンスがかなり向上します。最低 80 パーセントのヒット率は良い目標ですが、可能であればそれよりも高いヒット率を目標にすることが望まれます。

スレッドの使用

Web コンテナツールを使用して、要求を処理するために使用するスレッドの数を監視します。一般に、実際に使用されるスレッドの数は多くの場合予測した数よりも少なく、特に CPU の使用率が通常 100 パーセントよりもかなり低い本稼働サイトではそのようになります。

ポータルの使用情報

Portal Server には、ポータルのユーザーがポータルの使用情報を監視するための組み込みの報告メカニズムがあります。これには、アクセスされるチャネル、チャネルがアクセスされた期間、またポータルのユーザーの行動様式を作成する能力が含まれます。ポータルの監視は、psconsole または cli psadmin を使用して管理できます。次の監視機能を使用できます。

ユーザーベースの追跡 (UBT) も、psconsole または cli psadmin を使用して管理されます。UBT はデフォルトでは無効になっています。ユーザーベースの追跡を有効にするには、ファイル /var/opt/SUNWportal/portals/portal1/config にあるプロパティー com.sun.portal.ubt.enable=true を設定する必要があります。取得されたデータのエクステントは、レベル INFO、FINE、FINER、 FINEST、OFF が制御します。ログは、/var/opt/SUNWportal/portals/portal1/logs/%instance/ubt.%u.%g.log ファイルにルーティングされます。このファイルは設定可能です。

アイデンティティーとディレクトリ構造の設計

ポータルの実装の主な部分は、ディレクトリ情報ツリー (DIT) の設計です。DIT は、ユーザー、組織、サブ組織などを論理構造または階層構造に編成することにより、管理を効率的に行い、適切なアクセス権限をユーザーに割り当てることを可能にします。

Access Manager の組織ツリー の最上位は、デフォルトで dc=fully-qualified-domain-name と呼ばれ、インストール時に変更または指定できます。インストール後に、追加の組織を作成して、別の企業を管理することができます。作成された組織はすべて最上位組織の下に配置されます。これらのサブ組織内で、他のサブ組織を入れ子にできます。入れ子の構造の深さには制限がありません。

注 –

ツリーの最上位を dc と呼ぶ必要はありません。必要に応じてこの名前を変更できます。ただし、たとえば、dc など一般的な最上位で編成されたツリーでは、ツリー内の組織はロールを共有することができます。

ロールは、より効果的に、またより簡単にアプリケーションを使用するように設計されたグループ化メカニズムです。それぞれのロールはメンバー、あるいはロールを保有するエントリを持ちます。グループの場合と同じく、ロールのメンバーは明示的またはダイナミックに指定できます。

ロールメカニズムにより、そのエントリがメンバーになっているすべてのロール定義の識別名 (Distinguished Name、DN) を含む nsRole 属性が自動的に生成されます。各ロールは、1 人または複数のユーザーに付与できる、単一の権限や権限のセットを含んでいます。複数のロールを 1 人のユーザーに割り当てることができます。

ロールの権限はアクセス制御命令 (ACI) で定義されます。Portal Server には、いくつかのロールが事前に定義されています。Portal Server 管理コンソールを使用してロールの ACI を編集し、ディレクトリ情報ツリー内でアクセス権を割り当てることができます。用意されている例には、SuperAdmin Role および TopLevelHelpDeskAdmin ロールが含まれます。組織間で共有できるその他のロールを作成することもできます。

カスタム Access Manager サービスの作成

Access Manager のサービス管理は、Access Manager サービスとして属性のグループを定義、統合、および管理する手段になります。

管理のためにサービスを準備するには、次の手順が伴います。

Access Manager および Directory Server 構造の計画に関する詳細については、『Sun Java System Portal Server Secure Remote Access 6 2005Q4 管理ガイド』、『Sun Java System Directory Server Enterprise Edition 6 2006Q1 配備計画ガイド』および『Access Manager 配備計画ガイド』を参照してください。

ポータルデスクトップの設計

Portal Server のパフォーマンスは、個々のチャネルの実行速度によって決定されます。また、ポータルに対するユーザーの体感は、ポータルデスクトップが表示される速度に基づきます。ポータルデスクトップは、最低の速度で表示されるチャネルと同じ速度でのみ読み込みを行うことができます。たとえば、10 個のチャネルから構成されるポータルデスクトップを考えてみます。9 つのチャネルが 1 ミリ秒で描画されるが、10 番目のチャネルが 3 秒かかる場合は、ポータルデスクトップはポータルが 10 番目のチャネルを処理するまで表示されません。各チャネルが要求を最短時間で処理できるようにすることによって、ポータルデスクトップのパフォーマンスの向上を実現できます。

正しい集約方針の選択と実装

速度とスケーラビリティーの向上を目的としてポータルチャネルを実装するために選択できるいくつかの方法を次に示します。

プロバイダの操作

プロバイダの配備を計画するときには、次のことを考慮します。

ソフトウェアの配備

このセクションでは、ソフトウェアのパッケージ化メカニズム、システム内部のソフトウェアカテゴリ、および Java ソフトウェアとの互換性について説明します。

ソフトウェアのパッケージ化

Portal Server では、「動的 WAR ファイル」のアプローチを使用して、ソフトウェアをシステムに配備します。Portal Server は SolarisTM パッケージを使用してインストールされます。Solaris パッケージは、JAR、JSP、テンプレート、および HTML ファイルなど、Web アプリケーションを構成する個々のファイルで構成されています。パッケージには、WAR ファイルや EAR ファイルは含まれていませんが、インストール時に Portal Server WAR ファイルを構成するために使用する、web.xml フラグメントが含まれています。この動的に構成されるファイルが、Web アプリケーションコンテナに配備されます。ローカリゼーションなどの場合に追加パッケージがシステムにインストールされると、Web アプリケーションファイルは再構成および再配置されます。

注 –

WAR ファイルのパッケージ化と配備の仕組みは、Portal Server 製品だけが使用します。現行では、WAR ファイルや WAR ファイルを構成するために使用されるファイルにユーザーが変更を加えることはできません。

ソフトウェアのカテゴリ

Portal Server は、Portal Server ノードにインストールするソフトウェアの種類を、次のように区別します。

注 –

静的 Web コンテンツと動的 Web アプリケーションは、すべて 1 つの WAR ファイルにグループ化されます。

Java ソフトウェアとの互換性

Portal Server ソフトウェアは、次の 3 つのカテゴリに分けられます。

クライアントのサポート

Portal Server は次のブラウザをクライアントとしてサポートします。

HTML、WML、またはその他のプロトコルのどれに基づいていようと、複数のクライアントタイプが、Access Manager に、またその結果 Portal Server にアクセスできます。この機能を有効にするには、Access Manager はクライアント検出サービス (クライアント検出 API) を使用してポータルにアクセスするクライアントのタイプを検出します。次に、そのクライアントタイプを使用して、出力に使用するポータルテンプレート、JSP ファイル、および文字エンコーディングを選択します。

注 –

現在、Access Manager は、Internet Explorer や Netscape Communicator などのサポートされている HTML クライアントブラウザに対するクライアントデータのみを定義します。詳細については、Access Manager のマニュアルを参照してください。

Sun Java System Portal Server Mobile Access ソフトウェアは、Portal Server プラットフォームのサービスと機能をモバイルデバイスへ拡張し、音声アクセスのためのフレームワークを提供します。このソフトウェアは、HTML ブラウザを使用してアクセスする場合と同じコンテンツをポータルサイトのユーザーが入手できるようにします。

Mobile Access ソフトウェアは、xHTML、cHTML、HDML、HTML、WML などのモバイルマークアップ言語をサポートします。このソフトウェアは、HTTP または HTTPS のどちらかのプロトコルを使用して、LAN または WAN 経由でワイヤレスネットワークに接続されているモバイルデバイスをサポートできます。実際に、Portal Server Mobile Access ソフトウェアは、オートモバイル、セットトップボックス、PDA、携帯電話、音声など任意の数のデバイスをサポートできます。

コンテンツと設計の実装

ポータルデスクトップは、Portal Server のプライマリエンドユーザーインタフェースであり、プロバイダアプリケーションプログラミングインタフェース (PAPI) による広範なコンテンツ集約のメカニズムを備えています。ポータルデスクトップには、コンテナ階層と、特定のチャネルを構築するための基本構築ブロックとを有効にするさまざまなプロバイダが表示されます。コンテンツプロバイダとチャネルデータを保存する場合、ポータルデスクトップは Access Manager サービスのトップでディスプレイプロファイル データ保管メカニズムを実行します。

コンテンツの集約に使用できるさまざまな技術を次に示します。

詳細については、『Sun Java System Portal Server 7.1 Secure Remote Access 管理ガイド』および『Sun Java System Portal Server 7.1 Developer Sample Guide』を参照してください。

静的なポータルコンテンツの配置

静的なポータルコンテンツは、web-container-instance-root / https-server/docs ディレクトリまたは web-container-instance-root/directory/https-server/docs ディレクトリ (Web コンテナのドキュメントルート) 下のサブディレクトリに配置します。web-container-instance-root/SUNWportal/web-apps/https-server/portal/ ディレクトリは非公開のディレクトリであるため、コンテンツをこのディレクトリに配置しないでください。このディレクトリに配置されたコンテンツは、パッチまたはその他の更新時に Portal Server の Web アプリケーションが再配備されたときに削除の対象になります。

アプリケーションの統合

アプリケーションの Portal Server との統合および配備は、配備作業の中でも、もっとも重要な作業の 1 つです。アプリケーションのタイプを次に示します。

Microsoft Exchange と Sun Java System Messaging Server の統合

JavaMailTM API の使用は、Microsoft Exchange メッセージングサーバーを Portal Server と統合する主なオプションの 1 つです。JavaMail API は、Java テクノロジに基づいたメールおよびメッセージングアプリケーションを構築するためのプラットフォーム独立およびプロトコル独立フレームワークです。JavaMail API は、Java プラットフォームのオプションのパッケージとして実装され、任意のオペレーティングシステムの JDK 1.4 以降で利用できます。JavaMail API は、Java Platform, Enterprise Edition (Java EE) に必須です。

JavaMail は、メールを管理するための共通の統一 API を提供します。JavaMail は、サービスプロバイダが Java プログラミング言語を使用して標準ベースのまたは独自のメッセージングシステムへの標準のインタフェースを提供するのを可能にします。この API を使用して、アプリケーションはメッセージストアにアクセスし、メッセージを作成および送信できます。

独立ソフトウェアベンダー

次に独立ソフトウェアベンダー (ISV) の統合機能のいくつかのタイプを示します。

注 –

Portal Server 7.1 は、amsdk の使用に依存しています。制限レルムモードのサポートも可能ですが、Portal Server 7.1 はデフォルトではレガシーモードをインストールします。Sun One Java Directory Server 6 とすべての LDAPv3 ディレクトリサーバーがサポートされています。

Portal Server とユーザーインタフェースの統合が行われる「深さ」の程度は、統合がどれだけ徹底したものかを示します。深さは、統合の補完的な性質を説明するために使用する用語であり、次のようなアイテムを指します。

一般に、アプリケーションが Portal Server と統合する程度は、次のように見なすことができます。

本稼動配備への移行

パイロットまたは概念実証配備がテスト基準をクリアすると、配備を本稼働環境に移行する準備が整っています。通常は、本稼働環境には段階的に移行します。段階的な移行は、多数のユーザーに影響を及ぼす大規模な配備において特に重要です。

段階的な配備は少数のユーザーから開始し、配備がすべてのユーザーに対して提供されるまでユーザーベースを徐々に拡大していきます。また、少数のサービスから開始し、残りのサービスへと段階的に行なう方法もあります。段階的なサービス提供を計画的に実行すると、本稼動環境で発生しうるサービス関連の問題を切り分け、特定、および解決するうえで役立ちます。