第 4 章配備前の注意点

ポータルのチューニングに入る前に、ポータルシステム管理者およびポータル開発者と話し合い、計画される要件に基づいてポータルのパフォーマンス目標を設定します。目標には、ユーザー数、負荷ピーク時の並行処理ユーザー数、および Sun Java^TM System Portal Server にアクセスする際のユーザーの使用パターンなどがあります。

ポータルアプリケーションの迅速な応答を目指してチューニングするのか。

多数のユーザーの並行処理に対応できるようにチューニングするのか。

並行してポータルに接続するユーザー数が増加すると、ハードウェアとパラメータセットが同じであれば、応答時間が減少します。そのため、Sun Java System Portal Server の予想使用レベル、任意の時刻に予想される並行処理ユーザー数、ポータルデスクトップのアクティビティー要求数、ポータルチャネル使用量、組織によって決定されるエンドユーザーへの許容応答時間、および基準を満たす最適ハードウェア構成に関する情報を収集してください。

ポータルのサイジングのヒント

このセクションでは、サイジングプロセスで役立つヒントを紹介します。

企業対顧客用ポータルでは、ゲートウェイと SSL を使用するために SRA を配備する必要があります。サイジング要件には、必ずこの点を盛り込んでください。SSL を有効にすると、SSL なしの場合に比べ、ポータルのパフォーマンスが最大で 1/10 にまで低下します。

企業対社員用ポータルの場合は、基準として使用できるユーザープロファイルがあることを確認してください。

どんなポータルであっても、余裕をもって構築して成長に備えます。つまり、現状の必要に合わせてサイジングするだけでなく、将来の必要と能力も考慮に入れます。これには、週末や祝日などの休日明けに生じる通常のピークの場合、またはポータルがより「スティッキー」であるために時間の経過とともに使用量が増加する場合などがあります。

地理的に複数のサイトに渡ってポータルソリューションを配備する場合は、ネットワークとデータセンターの配置を十分理解している必要があります。

必要な冗長機能のタイプを判断してください。生産ダウンタイム、アップグレード、およびメンテナンス作業などの要素を考慮します。ポータルサーバーの運用を停止する場合は、通常、処理能力に与える影響が全体の処理能力の 1/4 を超えないようにします。

一般に、企業対社員用ポータルの使用並行性は、企業対顧客用ポータルの場合より高くなります。

パフォーマンス方法論の確立

パフォーマンス目標を設定したら、次の手順に従ってポータル環境をチューニングします。

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

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

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

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

「ポータルのサイジング」を参照してください。

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

「分析ツール」を参照してください。

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

ポータルのサイジング

Portal Server の基準サイズを設定する必要があります。基準サイズを設定し、その数値を検証および微調整することで、スケーラビリティーな、高可用性、信頼性のある、優れたパフォーマンスを実現できます。

ポータルのサイジングプロセスは、以下のステップで構成されます。

以下のセクションではこれらのステップについて説明します。

基準サイズの確立

ビジネス要件と技術要件を特定し、Portal Server の機能と必要事項をマッピングすると、全体的な Portal Server の配備計画が進むにつれ、サイジング要件も判明してきます。設計上の決定事項は、Portal Server のユーザーセッションと並行性に関する正確な見積もりを作成する際に役立ちます。

Sun Java System の技術担当者は、Portal Server の配備で必要になる CPU の数の見積もりを算出する自動サイジングツールを提供します。サイジングツールへの入力値として、以下のメトリクスを収集する必要があります。


注	Sun Java System Portal Server Secure Remote Access (SRA) ソフトウェアを使用した安全性の高いポータル配備のサイジング要件は、「SRA サイジング」で説明されています。

Portal Server の配備で必要になる CPU の数に影響を与えても、サイジングツールでは使用されないその他のパフォーマンスメトリクスは次のとおりです。

ポータルデスクトップ設定

ハードウェアとアプリケーション

バックエンドサーバー

トランザクション時間

ワークロード条件

これらのパフォーマンス要因については、続くセクションで説明します。

ピーク数

最大並行セッション数は、配備される Portal Server で処理可能な接続ユーザー数を定義します。

最大並行セッション数を計算するには、次の計算式を使用します。

企業ポータルの見込みユーザーのユーザーベースサイズまたはプールサイズを特定するには、次の提案を参考にしてください。

アクティブなユーザーのみを識別します。たとえば、休暇や休日をとっているユーザーは対象にしません。

ユーザーベースには有限数を使用します。匿名ポータルの場合は、この数字を控えめに見積もります。

アクセスログを調べます。

ユーザーベースの地理的な場所を識別します。

ビジネス計画の中でユーザーについて記述した内容について忘れないでいてください。

ページ要求間の平均時間

ページ要求間の平均時間は、Portal Server からユーザーがページを要求する頻度の平均です。ページには、ポータルにログインしたときの最初のログインページや、ポータルデスクトップからアクセスする Web サイトや Web ページなどがあります。1 ページの表示とは、ページに配置されているアイテム数に関係なく、1 回の呼び出しで表示される 1 つの情報ページを指します。

Web サーバーのログにはページ要求が記録されますが、ログを使用して要求から要求までの平均時間をユーザー単位で計算することはできません。ページ要求間の平均時間を計算するには、WebLoad パフォーマンステストツールのような市販の統計ツールが必要です。ツールを使用して得られた数値を基にして、並行処理ユーザー数を判断できます。



注	ページ要求を基準にすると、「ヒット数」を基準にするよりも Web サーバーのトラフィックを正確に測定できます。Web サーバーからのファイル要求は、1 ヒットとして毎回計上されます。ページにあるすべてのアイテムが登録されているので、1 回のページ呼び出しで何度もヒットが記録されます。たとえば、10 個のグラフィックファイルが組み込まれているページの場合は、HTML ページ自体で 1 回、および 10 個のグラフィックファイルそれぞれが 1 回ずつカウントされ、合計 11「ヒット」が記録されます。したがって、ページ要求を基準にしたほうが Web サーバーのトラフィックをより正確に判断できます。

並行処理ユーザー

並行処理ユーザーは、実行中の Web ブラウザプロセスに接続し、Portal Server に要求を送信するか、要求の結果を受信しているユーザーです。最大並行処理ユーザー数は、あらかじめ定義された時間内に接続可能な並行処理ユーザーの最大数です。

最大並行処理ユーザー数は、最大並行セッション数を算出してから計算します。最大並行処理ユーザー数を計算するには、次の計算式を使用します。

たとえば、ユーザーが 50,000 人のイントラネット Portal Server の例について考えます。負荷ピーク時に接続されているセッション数を、登録されたユーザーベースの 80% と見積もります。ユーザーは、平均で 10 分に 1 回の割合でポータルデスクトップにアクセスします。

したがって、この Portal Server の負荷ピーク時に接続できる最大並行処理ユーザー数は 4,000 人になります。

平均セッション時間

平均セッション時間は、多くのユーザーを対象に算出した、ログインからログアウトまでの平均時間です。セッション時間の長さは、発生するログイン数に反比例します。つまり、セッション期間が長くなると、同じ並行処理ユーザーベースでの Portal Server に対する毎秒のログイン数が少なくなります。セッション時間は、ユーザーのログインからログアウトまでの時間です。

平均セッション時間は、多くの場合、ユーザーの Portal Server の使い方によって変化します。たとえば、対話型のアプリケーションが関係するユーザーセッションの場合は、情報のみのユーザーセッションの場合よりも、セッション時間が長くなるのが一般的です。

検索エンジンの要素

ポータルサイトで検索チャネルを提供する場合は、検索エンジンのサイジング要素をサイジングの計算に含める必要があります。検索エンジンのサイジング要件は、以下の要素によって決まります。

インデックスディレクトリのアクティブリストにあるインデックスパーティーションのサイズ

リソース記述 (RD) に必要な平均ディスクスペース

次の式を使用して計算します。

必要な平均ディスクスペース =
データベースサイズ / データベース内の RD 数

平均サイズは、RD サイズの変動に合わせて調整されます。多くのインデックス付き用語を使用した長くて複雑な RD の集合と、少数のインデックス付き用語による短い RD のリストでは、複雑な RD に同じ数の RD があっても、必要な検索時間が異なります。

RD は階層型データベース形式で保存されます。この形式では、RD が保存されていなくても、データベースの組み込みサイズを考慮する必要があります。

検索関連のアクティビティーを実行する並行処理ユーザーの数

次の式を使用して計算します。

並行処理ユーザー数 / 検索ヒット間の平均時間

「ページ要求間の平均時間」で計算される並行処理ユーザー数の値を使用します。

使用する検索演算子のタイプ

検索関数のタイプには、基本、結合、近接、パッセージとフィールド演算子、およびワイルドカードスキャンなどがあります。それぞれの検索関数では、異なる検索アルゴリズムとデータ構造を使用します。検索アルゴリズムとデータ構造の違いは、検索用語数とインデックス付き用語数の増加するのにつれて大きくなるので、検索関数のタイプは検索結果が返されるまでの時間に影響します。



ヒント	ここまでで、上述の数値を技術担当者に伝え、サイジングツールを実行して CPU の見積もり数を算出するように依頼できます。

ポータルデスクトップ設定

ポータルデスクトップの設定によって、セッション単位でメモリーに保持するデータ量が明確に決定されます。

ポータルデスクトップのチャネルが多くなるほど、データのセッションサイズは大きくなり、Portal Server のスループットが低下します。

もう 1 つの要素は、ポータルデスクトップで提供される対話機能の性能です。たとえば、チャネルをクリックすると、Portal Server または他の外部サーバーに負荷が発生します。チャネルの選択によって Portal Server に負荷が発生すると、ポータルデスクトップをホストするノードのユーザークティビティープロファイルと CPU オーバーヘッドは、他の外部サーバーをホストするノードの場合より高くなります。

ハードウェアとアプリケーション

CPU 速度と、Java^TM プラットフォーム (Java^TM 仮想マシンまたは JVM^TM ソフトウェア) のメモリーヒープにおける仮想マシンのサイズは、Portal Server のパフォーマンスに影響を与えます。

CPU 速度が速くなれば、スループットも高くなります。ヒープ生成チューニングパラメータとともに、JVM メモリーヒープのサイズも Portal Server のパフォーマンスを左右します。

バックエンドサーバー

Portal Server は外部ソースからコンテンツを集約します。外部のコンテンツプロバイダが、最大速度で動作する Portal Server に必要な帯域を確保できない場合、ポータルデスクトップのレンダリングとスループットの要求時間は最適化されません。ポータルデスクトップは、ブラウザに要求応答を返す前に、すべてのチャネル動作が完了するかタイムアウトになるまで待機します。

次のチャネルを使用する場合は、バックエンドのインフラストラクチャーを慎重に計画してください。

外部ソースからコンテンツを収集する

一般に応答時間の遅い企業データベースにアクセスする

電子メールコンテンツを提供する

カレンダコンテンツを提供する

トランザクション時間

トランザクション時間は、HTTP または HTTPS 処理が完了するまでの遅延時間で、送信時間、処理時間、および応答時間を合計した時間です。

トランザクション時間に影響する要素について計画する必要があります。これには、次の要素があります。

ネットワーク速度と待ち時間。

ポータルデスクトップの複雑さ。

ブラウザの接続速度。

たとえば、接続速度が 33.6 kbps の場合は、LAN 接続の場合よりも応答時間の遅延が長くなります。ただし、処理時間は一定です。ダイヤルアップ接続によるトランザクション時間は、データ圧縮を実行するロード生成ツールによって表示されるトランザクション時間よりも短くなります。

トランザクション時間を計算する場合は、Portal Server のサイジングを行なって、通常またはピーク時の負荷状態がパフォーマンス要件のしきい値を超えないように、また時間が経過しても処理時間を維持できるようにします。

ワークロード条件

ワークロード条件は、システムにおいてもっとも集中的に使用される、システムリソースと JVM ソフトウェアリソースです。これらの条件は、大部分がユーザーの動作と配備するポータルのタイプによって決まります。

Portal Server ソフトウェアで一般的に発生するワークロード条件は、次の要素に影響を与えます。

システムパフォーマンス

Portal Server のパフォーマンスは、アクティビティープロファイルが高い場合など、大量の並行要求が処理される場合に影響を受けます。たとえば、企業対企業ポータルの負荷ピーク時には、同時に大勢の社員がポータルに接続します。そうした状況では、CPU にワークロードが集中します。また、接続されたユーザーに対する並行処理ユーザーの割合も高くなります。

Portal Server の処理能力は、大勢のユーザーがログインすると影響を受け始めます。ログインするユーザーが多くなると、ユーザーがより多くのメモリー領域を使用するので、サーバーで要求を処理するために使用可能なメモリーが少なくなります。たとえば、企業対顧客 Web ポータルでは、ポータルデスクトップの初期表示がロードされるとすぐ、大勢のログインユーザーが外部の Web サイトにリダイレクトされます。しかし、さらに多くのユーザーがログインすると、Portal Server に要求を送信しているユーザーと単にログインしているだけのユーザーの割合が低くても、より多くのメモリー領域が必要になります。

日、週、または月の特定の時間帯におけるユーザーの動作に応じて、Portal Server は、CPU 集中のワークロードとメモリー集中のワークロードを切り替えることができます。ポータルのサイト管理者は、最重要なワークロード条件を定めて、企業のビジネス目標に合ったサイトのサイジングとチューニングを実行する必要があります。

基準サイズのカスタマイズ

Portal Server を配備する場合の適切な見積もりサイズを設定する作業は反復プロセスです。入力値を変更すれば、幅のあるサイジング結果を生成できます。Portal Server の配備方法をカスタマイズするとパフォーマンスが大きく変化します。

サイジングの見積もりが完了したら、次の点を考慮します。

LDAP トランザクション数

アプリケーションサーバーの要件

LDAP トランザクション数

以下の、工場出荷状態でポータルを配備する場合の LDAP トランザクション数を使用して、LDAP マスターとレプリカのサービス要求に与える影響を理解してください。これらの数字は、システムのカスタマイズを開始すると変更されます。

認証なしの匿名ポータルへのアクセス - 0 ops

ログインチャネルを使用したログイン - 2 BINDS、2 SRCH

ポータルデスクトップからのチャネルの削除 - 8 SRCH、2 MOD

ポータルデスクトップの再ロード - 0 ops

アプリケーションサーバーの要件

アプリケーションサーバーにインストールされた Portal Server の主な使用法の 1 つは、ポータルプロバイダを、アプリケーションサーバーで動作している Enterprise JavaBeans^TM アーキテクチャー、および JDBC や JCA などの他の J2EE^TM テクノロジスタック構造体と統合することです。これら他のアプリケーションとモジュールはリソースを消費するので、ポータルのサイジングに影響があります。

基準サイズの検証

ここまでで、ポータルを配備する場合の CPU の見積もり数が算出されるので、試験的な配備を行なってポータルのパフォーマンスを測定します。ロードバランス機能を使用して、ストレステストを実行して、次の要素を決定します。

スループット: 指定された時間内に処理されるデータ量です。

待ち時間: 1 つのコンポーネントが別のコンポーネントを待つときの時間です。

最大並行セッション数。

Portal Server にはポータルのサンプルが用意されています。使用するチャネルに類似のチャネルでサンプル使用し、システムに負荷をかけることができます。サンプルはポータルデスクトップにあります。

試験的な配備を使用して、最終的なサイジング見積もりを決定します。試験的な配備により、バックエンド統合をサイジングし、Portal Server の動作に関係する潜在的なボトルネックを回避します。

基準サイズの微調整

次のステップでは、導き出したサイズを微調整します。このセクションでは、スケーラビリティー、高可用性、信頼性、および優れたパフォーマンスを特長とするポータルサイトを配備できるように、適切な量の余裕値を組み込みます。

基準サイズは多くの見積もり値に基づいて導き出されるので、微調整してから使用してください。


注	SRA を使用してセキュリティー保護するポータル配備の基準サイジング要件については、「SRA サイジング」で説明されています。

見積もられた基準サイズを基準点として使用します。

基準サイズからの変動量を予想します。

他の人の経験から学びます。

自分の判断力と知識を活用します。

配備における他の要素について検討します。

Portal Server の配備に、いくつかの大陸におよぶ複数のデータセンターと一様なトラフィックが関係している場合は、1 つの大陸でトラフィックの大きな 2 つの単独データセンターを使用する場合よりも、最終サイズを大きくする必要があります。

変更計画

ポータルサイトは、運用を開始してからさまざまな変更が加えられることがよくあります。たとえば、次のような変更が加えられることがあります。

チャネル数の増加

ユーザーベースの増大

ポータルサイトの目的の変更

セキュリティーの必要事項の変更

電源障害

メンテナンス要求

これらの要素について考慮すれば、柔軟性に富んだ見積もりサイズを導き出すことができ、ポータルの想定内容が配備後に変更される場合のリスクを回避できます。

導き出される見積もりサイズにより、ポータルサイトの次の特長を確保することができます。

スケーラビリティー、高可用性、信頼性、および優れたパフォーマンス

望むサービスをすべて提供する余裕

変更に対応する柔軟性

最終基準サイズの検証

試験的な配備を使用して、ポータルの配備方法がビジネス要件と技術要件を満たすことを検証します。

SRA サイジング

このセクションは、組織において、SRA をインストールして安全性の高いポータルを実装する場合にのみお読みください。ポータルの場合に行なったのと同様、SRA の場合にも、最初にゲートウェイインスタンスの基準見積もりサイズを設定する必要があります。1 台のマシンにインストールできるゲートウェイは 1 つだけですが、複数のインスタンスを持つことはできます。SRA により、それぞれが複数のインスタンスで動作する複数のゲートウェイをインストールできます。設計上の決定事項は、SRA のユーザーセッションと並行性に関して正確な試算を行うのに役立ちます。

まず、ゲートウェイインスタンスの基準サイジング見積もりを設定する必要があります。この基準値は、ゲートウェイのユーザーセッションと並行処理の必要に応じて満たす必要のある条件を示しています。

SRA を配備する場合の適切なサイジング試算値を決定する作業は、反復プロセスです。入力値を変更すれば、幅のあるサイジング結果を生成できます。これらの結果をユーザーの本来の要件に照らしてテストします。要件を正しく定義し、SRA のパフォーマンスとして実際的な値に設定すれば、パフォーマンスが関係するほとんどの問題を回避できます。

このセクションでは、ゲートウェイインスタンスの基準サイジングプロセスが関係する次のタイプのパフォーマンス要素について説明します。

ゲートウェイの主要なパフォーマンス要件の特定

ゲートウェイの詳細設定

ゲートウェイの主要なパフォーマンス要件の特定

主要なパフォーマンス要素とは、技術担当者が自動サイジングツールへの入力値として使用するメトリクスのことです。サイジングツールは、SRA を配備する際に必要となるゲートウェイインスタンスの見積もり数を算出します。

これらの主要なパフォーマンス要素を特定し、それを技術担当者に伝えることは、基準サイズを決定するための第一歩です。



注	ゲートウェイを適正にサイジングする作業は複雑なので、ゲートウェイのサイジングツールを使用する段階は単なる始まりにすぎません。ゲートウェイのパフォーマンスはスループットに大きく依存し、それ以外にもユーザー数、アクティブユーザー数、またはユーザーセッション数が影響します。ゲートウェイのサイジング情報は、前提セットに基づいている必要があります。詳細については、152 ページの「Secure Remote Access Example」を参照してください。

セッション特性

Netlet の使用特性



注	これらの主要なパフォーマンス要素を計算し終えたら、技術担当者に計算値を伝えます。ゲートウェイのサイジングツールを実行して、ゲートウェイインスタンスの見積もり数を導き出すように依頼します。

セッション特性

SRA (ゲートウェイ) ユーザーの合計数

最大負荷時にゲートウェイを使用する合計ユーザーの予想割合

ページヒット間の平均時間

セッション平均時間

Netlet の使用特性

以下に示すゲートウェイの Netlet 特性について考慮してください。これらの特性は、ゲートウェイインスタンス数の計算に影響を与えます。

Netlet は、Access Manager 管理コンソールで有効にします。

Netlet を有効にした場合は、ゲートウェイは着信トラフィックが Netlet トラフィックであるか、または Portal Server トラフィックであるかを判断する必要があります。Netlet を無効にした場合は、ゲートウェイはすべての着信トラフィックが HTTP トラフィックと HTTPS トラフィックのいずれかであると仮定するため、オーバーヘッドが低減します。Netlet は、Portal Server でリモートアプリケーションをまったく使用しないことが確実な場合にだけ無効にしてください。

Netlet を使用する合計ユーザーの予想パーセンテージ

予想スループット

使用される Netlet 暗号化方式

ゲートウェイの詳細設定

Portal Server の配備で使用するゲートウェイインスタンスの数を見積もる際に、このセクションの設定を使用して、より正確な数値を得ることができます。これらの詳細なゲートウェイの設定値は、自動サイジングツールの入力値として使用します。

ページ設定

スケーラビリティー

セキュリティー保護されたポータルパイロット測定数



注	CPU の見積もり数に対する計算結果を技術担当者から得たら、これらの関連するパフォーマンス要素がその計算結果に与える影響について考察します。

ページ設定

認証されたポータルを使用する場合は、自動サイジングツールのページ設定セクションにある「Login Type」と「Desktop Type」の両方を指定する必要があります。

Login Type: エンドユーザーがユーザー名とパスワードを入力したときに、エンドユーザーに最初に表示されるポータルページ (コンテンツ設定と配信方法) のタイプを記述します。このプロセスでは、クレデンシャルの確認、セッションの初期化、および初期コンテンツの配信などが行われるので、システムにかかる負担が大きくなるのが一般的です。

Desktop Type: 最初のポータルページのあとにエンドユーザーに表示されるポータルページ (コンテンツ設定と配信方法) のタイプを記述します。これらのページは、そのあとに続くポータルとの対話型操作のたびに、またはデスクトップを更新したときに表示されます。セッションがすでに確立され、キャッシュされたコンテンツを利用できるので、通常必要とするシステムリソースが少なくて済み、ページがより短時間で配信されます。

ログインタイプとデスクトップタイプの両方の場合に、次の適切なコンテンツ設定を選択します。

Light-JSP: それぞれ 5 個のチャネルを持つ、2 つのタブの設定を記述します。

Regular-JSP: それぞれ 7 個のチャネルを持つ、2 つのタブの設定を記述します。

Heavy-JSP: それぞれ 17 個のチャネルを持つ、3 つのタブの設定を記述します。

スケーラビリティー

ゲートウェイインスタンスあたり、1 個、2 個、および 4 個の CPU を選択できます。ゲートウェイインスタンスにバインドされた CPU の数により、配備に必要なゲートウェイインスタンスの数が決まります。

セキュリティー保護されたポータルパイロット測定数

SRA ポータルのパイロットから得られた数値がある場合は、ゲートウェイサイジングツールでそれらの数値を使用して、より正確な結果を導き出すことができます。次の値を入力します。

測定された CPU パフォーマンス: ゲートウェイインスタンスの数を計算するために使用される値には、次のようなものがあります。

初期ポータルデスクトップ表示、CPU あたりの毎秒ヒット数

ポータルデスクトップ再ロード、CPU あたりの毎秒ヒット数

Netlet アプリケーションのブロックサイズ: この値により、Netlet アプリケーションのバイトサイズを指定します。Netlet は、使用するアプリケーションに基づいてブロックサイズを動的に決定します。Telnet 用に Netlet によって決定されるブロックサイズは、転送されるデータの量に基づいて決定されます。



注	試験的な配備数を使用する場合は、「Page Configuration」オプションと「Scalability」オプションを指定する必要はありません。

SRA ゲートウェイと SSL ハードウェアアクセラレータ

SRA ゲートウェイのような SSL 集中サーバーは、毎回のセキュリティー保護トランザクションで要求される暗号化を実行するために、大きな処理能力を必要とします。ゲートウェイのハードウェアアクセラレータを使用すれば、暗号化アルゴリズムの実行速度が上がり、動作速度が向上します。

Sun Crypto Accelerator 1000 ボードは、公開鍵と対称暗号化を加速する暗号化コプロセッサとして機能するショート PCI ボードです。この製品には外部インタフェースがありません。ボードは内部 PCI バスインタフェースを通じてホストと対話します。このボードの目的は、電子商取引アプリケーションのセキュリティープロトコルのために、計算を中心とするさまざまな暗号化アルゴリズムを高速化することです。

Sun Crypto Accelerator 1000 ボードと他のアクセラレータの詳細については、『Portal Server Secure Remote Access 6 管理ガイド』を参照してください。



注	Sun Crypto Accelerator 1000 ボードは、SSL ハンドシェークのみをサポートしており、対称鍵アルゴリズムはサポートしていません。これは、他のすべての暗号化アクセラレータと同様ではありません。他の暗号化アクセラレータも市場に出ており、中には対称鍵暗号をサポートするものもあります。詳細については、次の URL にアクセスしてください。 http://www.zeus.com/products/zws/security/hardware.html

Netlet プロキシとリライタプロキシのマシンでハードウェアアクセラレータを使用すれば、パフォーマンスをある程度改善できます。

SRA と Sun Enterprise ミッドフレームライン

通常の本稼働環境では、Portal Server と SRA を別々のマシンに配備します。ただし、複数のハードウェアドメインをサポートする Sun Enterprise^TM ミッドフレームマシンの場合は、同じ Sun Enterprise ミッドフレームマシンの異なるドメインに Portal Server と SRA の両方をインストールできます。Portal Server と SRA に関係する通常の CPU とメモリーの要件は引き続き適用されるので、それぞれの要件を別々のドメインに実装します。

このタイプの設定では、セキュリティーの問題に注意します。たとえば、ほとんどの場合、Portal Server ドメインはイントラネットに配置され、SRA ドメインは DMZ に配置されます。