| Oracle® Real User Experience Insightインストレーション・ガイド 12c リリース2 (12.1.0.3) for Linux x86-64 B70759-01 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightインストレーション・ガイド 12c リリース2 (12.1.0.3) for Linux x86-64 B70759-01 |
|
前 |
次 |
この章では、Oracle Real User Experience Insight (RUEI)の役割を示します。特に、RUEIのデータ・トラフィックの監視方法、操作要件および使用可能なデプロイメント・オプションを説明します。RUEIレポータ・データベース内で使用できる情報の量を増やす方法に関する情報も提供されます。
Webアプリケーションおよびサービスの利用は増え続けています。これには、マーケティング手段としてのインターネットの利用だけでなく、エクストラネットベースのサプライ・チェーンやバックオフィス統合、内部アプリケーションのイントラネット・デプロイも含まれます。明確に定義されたビジネス機能を実装したWebサービスの利用もますます増えています。RUEIは、これらすべてのデプロイ・シナリオの可用性およびパフォーマンスの測定、分析、改善のために設計されています。
通常、RUEIはWebサーバーの前、DMZ内のファイアウォールの後ろにインストールされます(図1-1)。データ収集方法は、ネットワーク・プロトコル分析(NPA)テクノロジに基づいています。この方法は100%非侵入的です。したがって、Webサーバーには負荷はかからず、パフォーマンスに影響を与えるソフトウェア・エージェントをインストールする必要もありません。さらに、現行のアプリケーションまたはインフラストラクチャに変更を加える必要もありません。アプリケーションの新リリースがデプロイされた場合、またはWebサーバーが増設された場合にも、RUEIの監視環境に対する変更はまったく、またはほとんど必要ありません。
ビジターがオブジェクトをリクエストすると、RUEIではそのリクエストを確認し、リクエストされたオブジェクトをビジターに示すまでにWebサーバーで要する時間を測定します。この時点で、RUEIは、ページをリクエストしたユーザー(クライアントのIP)、リクエストされたオブジェクト、オブジェクトのリクエスト元のサーバー(サーバーのIP)を知ることができます。
RUEIでは、Webサーバーが応答し、リクエストされたオブジェクトをビジターに送信するときに、そのレスポンスを確認します。この時点で、RUEIでは、サーバーからのレスポンスがあるかどうか、そのレスポンスが適切かどうか、リクエストされたオブジェクトの生成にWebサーバーが要した時間、およびオブジェクトのサイズを把握できます。また、RUEIでは、ビジターがオブジェクトを完全に受信したかどうか、またはビジターがダウンロードを中断したかどうか(つまり配信証明)も把握できます。したがって、RUEIはオブジェクトがインターネットを経由してビジターに到達するまでの時間を計算できるとともに、ビジターとサーバー間のインターネット・スループット(ビジターの接続速度)を計算できます。
RUEIは、図1-2に示すように、3つのレイヤーからなる製品アーキテクチャに基づいています。
監視対象のパケットは、表1-1に示すレイヤーによって処理されます。
表1-1 製品アーキテクチャ・レイヤー
| レイヤー | 説明 |
|---|---|
|
データ収集 |
このレイヤーは、RAWデータの取得とデータ・プロセッサ・レイヤーへの配信を担当します。このデータは、複数のソースから収集できます。使用可能な接続オプションについては、この項で後述します。 |
|
データ処理 |
このレイヤーでは、RAWデータがOLAPデータ・セットに変換されます。これは多次元データ構造を構成し、データ・ブラウザで表示できます。 |
|
データ・プレゼンテーション(レポータ) |
このレイヤーは、RUEIの分析およびレポート作成環境です。これは、Webベースの情報ポータルで、サポートされている任意のブラウザからアクセスできます。 |
後の項で説明するように、これらの各レイヤーを同じシステムまたはスケーラビリティの問題で個別のシステムにデプロイできます。
HTTP(S)データ・ストリームを読み取るために、専用のソフトウェア・モジュールでTCP/IPパケット・ストリームを再アセンブルします。データ・コレクタにIP番号が割り当てられていないことと、これらのデータ・コレクタを使用するソフトウェアに機能的なIPスタックがないことから、RUEIではデータ・コレクタで受信される受信トラフィックに応答できません。これにより、RUEIは監視対象のネットワークから見えなくなり、完全にセキュアになります。
|
注意: RUEIでは非侵入的な方法でデータを収集するため、測定ポートでエラーが発生しても、再転送のリクエストはできません。 |
データ収集は、暗号化データを記録するように構成できます。これを容易にするには、WebサーバーのプライベートSSLキーのコピーをデータ・コレクタに設定する必要があります。また、RUEIを構成して、フォームまたはコンテンツのPOSTリクエストの引数の機密データのロギングを省略できます(データ・マスキング(またはブラインド)と呼ばれます)。
RUEIでは、ネットワーク通信の監視のために、コピー・ポート脚注1 とTAP脚注2 の両方の使用がサポートされています(10/100 Mbpsおよび1/10 Gbpsイーサネット接続がサポートされています)。コピー・ポートとTAPは、銅回線またはファイバ・ベースのネットワーク・インフラストラクチャで使用できます。どちらのデバイスでもネットワーク通信の非侵入的監視が可能ですが、これら2つの接続オプションには違いがあります。これについては、この項の後半で取り上げます。
SSLトラフィックおよびFormsトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタがTAPなどの信頼できるネットワーク・デバイスに接続されていることを確認する必要があります。さらに、コレクタの「統計」ウィンドウ(「システム」、「ステータス」、「コレクタ・ステータス」の順に選択)から入手できる情報を定期的に調べ、TCPパケット・ストリームが完全な状態であることを確認するよう強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
コピー・ポートは、受信する様々なパケットのソースMACアドレスに基づいてレイヤー2転送表の作成を開始するスイッチです。この転送表の作成後、スイッチは、MACアドレス向けの通信を直接対応するポートに転送します。
たとえば、図1-3のWebサーバーMACが確認されると、ブラウザからWebサーバーへのユニキャスト通信は、Webサーバー・ポートにのみ転送されます。したがって、コレクタではこの通信は確認されません。
図1-3の下の部分に示した構成では、コレクタはブラウザが送信するすべてのパケットのコピーを受信するように構成されているポートに接続されています。このポートをコピー・ポートと呼びます。コピー・ポートは、任意またはすべてのデータ・ポートからの通信を1つの未使用ポートにコピーでき、ポート上での双方向の通信を防いで、ネットワークに通信が逆流しないように保護します。
スイッチ上でコピー・ポートをアクティブ化するとパフォーマンスに影響する可能性がある点に注意してください。通常、コピー・ポートでは広範な構成オプションがサポートされていますが、これらのオプションの詳細は、使用しているスイッチのドキュメントを参照するか、ベンダーにお問い合せください。
TAPは、任意の2つのネットワーク・デバイス(ルータやファイアウォールなど)の間に配置できます。TAPに接続されたすべての監視デバイスは、すべてのエラーも含めて、インラインであるかのように同じ通信を受信します。これは、TAPでリンク上のすべての通信を複製し、それを監視ポートに転送することにより実現します。図1-4の例は、1つのコレクタに対する典型的なTAPのデプロイを示しています。
重要:
コピー・ポートと異なり、TAPでは停電の場合にも、引き続きネットワーク・デバイス間でデータが流れます。また、コピー・ポートは負荷がかかったとき、パケットが失われやすくなります。TAPデバイスは、銅回線またはファイバ・ベースのインフラストラクチャに使用できます。さらに、必要な時と場所に簡単にデプロイでき、しかもスイッチの再構成や、ネットワーク・リンクのケーブル再配線に必要なエンジニアも必要ありません。これらの理由で、コピー・ポートよりもTAPの使用を強くお薦めします。
概して、TAPには、ネットワークTAP、再生成TAPおよび集約TAPの3タイプがあります。RUEIでは、ネットワークTAPと再生成TAPの使用がサポートされています。アグリゲーションTAPは、データが失われる可能性があり、許容レベルの正確さを提供できないため、お薦めできません。ただし、複数のコレクタのデプロイ、または1つのコレクタへの複数リンクの直接接続を、複数のストリームからのデータの集約に使用できます。また、ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。
RUEIシステムをレポータ、コレクタまたは処理エンジンのいずれかにインストールできます。これらの各インストール・オプションについては、この後の項で説明します。
レポータ
レポータ・システムは、接続されたコレクタによって収集されるデータを処理します。処理後に、このデータがレポータ・データベースと呼ばれるOracleデータベースに格納されます。システム・ユーザーは、ブラウザベースのインタフェースを通して収集されたデータを確認できます。
RUEIでネットワーク・トラフィックを正確に監視して結果をレポートするには、ネットワークおよびアプリケーション・インフラストラクチャの特定の情報が必要です。これには、ページ、サービス関数コールおよびエンド・ユーザーの識別方法、ネットワーク環境での監視範囲、特定のKPIおよびSLAの監視、システム・ユーザーに割り当てられるロールおよび権限が含まれます。この情報は、個別の構成データベースに保持されます。
コレクタ
コレクタは、ネットワーク・トラフィックを監視し、収集されるデータをレポータに送信します。複数のコレクタを同じレポータに接続することができます。コレクタ・システムおよびレポータ・システムの間に直接接続が必要なことに注意してください。
各レポータ・インストールには、ローカルのコレクタ・インスタンスも含まれていることに注意してください。レポータを構成して、このローカルのコレクタで収集される情報を処理したり、追加のコレクタから情報を受信できます。レポータ・システム上のローカルのコレクタ・インスタンスは、必要なければ無効にすることもできます。
処理エンジン
処理エンジンは、通常はレポータによって実行されるデータ処理を負担するRUEIデプロイメントのオプション・コンポーネントです。基本的に、コレクタによって収集されるデータを処理するオーバーヘッドを1つ以上の個別のシステムにオフロードすることが含まれます。
各処理エンジンには、中間ネットワーク・トラフィック監視結果が格納される固有(ローカル)のデータベースがあります。処理されると、このデータを使用してレポータのデータベースを更新します。すべての構成情報もこのデータベース内に維持されます。処理エンジン・システムごとに、関連付けられたコレクタ・システムおよびレポータ・システム間の直接接続が必要です。
前述のように、レポータ・システムを介して入手可能なデータは、レポータ・データベースと呼ばれるOracleデータベースに格納されます。監視対象のアプリケーションおよびシステム・ユーザーの情報など、Webインフラストラクチャで正しく監視およびレポートするためにRUEIで必要な情報は、データベースの個別の構成部分に保持されます。データベースは、ローカルのレポータ・システムに置くことも、リモート・データベース・サーバー(データベース・クラスタなど)に置くこともできます。
リモート・データベース・サーバーを使用すると、ローカルにインストールされたデータベースより潜在的に多くの利点があります。特に、既存のセキュリティおよびバックアップのポリシーと統合しやすく、さらに専用サーバーの使用によりパフォーマンスが向上します。
現在、RUEIはOracle 11gデータベースをサポートしています。11gR1の構成手順を説明しますが、11gR2もサポートしています。Oracle 10g(またはそれ以前の)データベースはサポートされていない点に注意してください。
この項では、使用できる様々なデプロイメント・シナリオに焦点を当てます。最適なデプロイメント・シナリオの選択は、監視されるネットワーク・トラフィックのレベル、レポート要件およびデプロイメント・システムのハードウェア仕様によって主に決定されます。
単一サーバーのデプロイメント
これは最も単純なデプロイメントで、トラフィックが小または中程度のレベルのWeb環境の監視に適しています。図1-5に例を示します。
このデプロイメントで、単一のシステムは、コレクタおよびレポータとして機能します。前述の項のように、レポータ・データベースをレポータ・システムまたはリモート・データベース・サーバーにローカルに置くことができます。
複数のサーバーのデプロイメント
非常に高レベルの通信を監視する必要がある場合、複数のサーバーの使用を検討できます。さらに、このデプロイにより、セキュリティが強化される可能性もあります。たとえば、コレクタをオフィス・ネットワーク外に配置する一方で、レポータ・システムをネットワーク内に配置する方法です。図1-6は、複数のコレクタのデプロイメントの例を示しています。
両方のデータ回線が同じレポート環境で監視されるデプロイメントを説明しています。このデプロイメントは、各回線上の通信が互いに排他的であることを前提としていることに注意してください。セキュリティ上の理由で使用されるデプロイメントも示しています。WebサーバーAおよびBからの通信が監視され、レポートが作成されるのに対し、WebサーバーCからの通信は監視もレポート作成も行われません。これは、コレクタがスイッチの上に配置されていない理由でもあります。レポータ・システムのコレクタ・インスタンス(システム1)が無効であることに注意してください。
セキュリティ上の理由から、レポータ・システムに対するアクセスは、信頼できるIPの範囲に制限することをお薦めします。同様に、レポータ・システムを内部ネットワークに配置して、セキュリティを最大限にすることができます。コレクタのデータ収集ポートはDMZ内に置く必要があります。
データベースに保持されるアプリケーションおよびインフラストラクチャ構成情報は、ブラウザベースのインタフェースを通してシステム・ユーザーが提供する情報に基づいて、レポータによって維持されます。各コレクタは、この情報を使用して、収集されるデータのレポート方法を決定します。
3層のデプロイメント
前述のように、処理エンジンは、通常はレポータによって実行される多くの処理を個別のシステムにオフロードします。レポータ・システムのCPU使用率が上限に達している場合、デプロイメント内の処理エンジンの使用を検討することを強くお薦めします。図1-7は、複数のコレクタのデプロイメント内の処理エンジンの例を示しています。
レポータ・システムで実行される処理に、接続されたコレクタで収集されたデータの処理だけでなく、エンリッチ・データ・エクスポート機能の使用も含まれることを理解する必要があります。これを使用すると、RUEIで収集されたデータを他のデータ・ソースと組み合せることができます。有効にすると、この機能がレポータ・システムに多くの追加の負荷をかけることに注意してください。エンリッチ・データ・エクスポート機能の使用方法の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
選択した構成(「インストール・オプション」で説明)に必要な最低限のシステム仕様については、この後の項で説明しています。
インフラストラクチャ用のネットワーク・カードの選択は、慎重に検討することをお薦めします。「接続オプション」で選択した接続オプションによっては、銅回線ベースおよびファイバベースの両方のネットワーク・カードが必要な場合があります。必要に応じて、ネットワークおよびシステムの両方の管理チームに相談してください。
|
注意: 必須および推奨のシステム仕様の詳細は、Oracleサポート・サービスにお問い合せください。 |
表1-2 単一サーバー・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
ネットワークTAPデバイスを使用する場合は脚注4 、3つ以上のネットワーク・インタフェースが必要。
|
|
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート( |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
脚注4 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。
表1-3 レポータ・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
1つ以上のネットワーク・インタフェースが必要。 |
|
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート(ttyUSB0)を使用します。テキスト・メッセージ送信の代替方法を使用できます(http/e-mail)。 |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
コレクタ・システムの要件を表1-4に示します。
表1-4 コレクタ・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルコア・プロセッサまたは同等のもの。 |
|
メモリー |
8GB。 |
|
ディスク領域 |
200GB以上のHDD空き領域脚注1 。 |
|
ネットワーク・インタフェース |
ネットワークTAPデバイスを使用する場合は脚注2 、3つ以上のネットワーク・インタフェースが必要。
ネットワーク・コピー・ポートを使用する場合、2つ以上のネットワーク・インタフェースが必要。
|
脚注1 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
脚注2 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成は使用できません。
脚注3 アップストリーム通信およびダウンストリーム通信用。アップストリームとダウンストリームの通信を1つの回線に統合するTAP(つまり、リンク集約TAP)の使用はお薦めできません。
処理エンジン・システムの要件を表1-5に示します。
表1-5 処理エンジン・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
1つ以上のネットワーク・インタフェースが必要。 |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
|
重要: Intel(またIntelと互換性のある)64ビット・プラットフォームは、すべてのデプロイメント・シナリオにおけるハードウェアとオペレーティング・システムでの必須要件です。 |
この項では、RUEIのデプロイメントを最適化するベスト・プラクティス・フレームワークを紹介します。次の情報を注意深く再検討することをお薦めします。
デプロイの計画
RUEIデプロイメント計画を決定する前に、監視対象のネットワーク環境の性質を明確に理解することが重要です。これには、基本的なネットワーク接続性、ポート、アドレス指定および物理デバイス要件だけではなく、監視対象のアプリケーションのしっかりした理解も含まれます。
さらに、RUEIをデプロイする前に、ネットワーク内の基本的な通信フローが確認されている必要があります。これには、平均およびピーク時の通信量に関する情報が必要です。物理デプロイ要件(スペースの制限、距離、電力計画、ラックのスペースおよびレイアウト、または配線など)も確認されている必要があります。
付録H「インストール・チェックリスト」で紹介しているチェックリストを使用すれば、この情報の大部分を取得できます。
Formsベースの通信
Formsベースの通信を監視する場合、メモリー要件は、「サーバーの要件」 に概説されているものよりも大きくなる可能性があることに注意してください。特に大量のForms通信を伴うデプロイの場合がこれに当てはまります。この場合は、分割サーバーのデプロイを検討する必要があります。
フル・セッション・リプレイ機能
フル・セッション・リプレイ(FSR)機能を利用する場合は、記憶容量追加の構成が必要になる可能性があります。これについては、「フル・セッション・リプレイの記憶域要件」で説明しています。
暗号化通信
監視対象の通信の相当な量が暗号化される場合、CPUのオーバーヘッドが増える可能性があります。この場合、CPUの追加または分割サーバー・デプロイの構成を検討することをお薦めします。
大量の通信
非常に多い量の(つまり、1日当たりのページ・ビューが1000万件を超える)通信を監視している場合、分割サーバー・デプロイを検討することを強くお薦めします。または、リモート・データベース・サーバーの使用を検討してください。後者には、レポート・システム上のCPUオーバーヘッドを大幅に(最大30%)減らす効果があります。監視対象環境の1日当たりのページ・ビューが2000万件を超える場合、分割サーバー・デプロイとリモート・データベース・サーバーの両方の使用を検討する必要があります。
『Oracle Real User Experience Insightユーザーズ・ガイド』で説明されているように、データ・ブラウザ内での特定データの可用性は、そのデータに基づくレポートと同様に、RUEIインストールに定義されたレポータ・データ保存ポリシーによって決まります。デフォルトでは、RUEIには情報が日、月、年の各レベルで32日、13か月および5年間保存されます。さらに、失敗したページ、URLおよびサービスに関する情報は、15日間保存されます。デフォルトのデータ保存ポリシーを維持するために必要なデータベース記憶域の最大量は、表1-6に示すとおりです。
表1-6 デフォルトの必須データベース記憶域
| 保存データの種類 | デフォルトの保存ポリシー | 期間当たりに必要なDB領域(GB) | 合計必須DB領域(GB) |
|---|---|---|---|
|
失敗したページ/URL/サービス |
15 |
1.5 |
22.5 |
|
日脚注1 |
32 |
1 |
32 |
|
月 |
13 |
1 |
13 |
|
年 |
5 |
1 |
5 |
|
スイート脚注2 |
32 |
1脚注3 |
32 |
|
追加のオーバーヘッド |
10 |
||
|
合計必須DB領域 |
114,5 |
脚注1 これには、「すべてのページ」、「すべてのセッション」、「すべての関数」、「すべてのトランザクション」、「キー・ページ」および「URL」の診断グループがあります。
脚注2 スイートでは、日の保存ポリシー設定が使用されます。
脚注3 構成されたスイートの種類ごとに、1日当たり1GBが必要です。
保存されるデータの種類ごとに必要なデータベース記憶域に加えて、他の目的のためにそれ相応の10GBのデータベース記憶域が必要であることに注意してください。これにはKPI、SLAおよび処理要件が含まれます。表1-6では、1種類のスイートが構成されていることを想定しています。
デフォルトのレポータ・データ保存ポリシーを変更する場合、「計算」機能を使用して、必須データベース記憶域に対する新しい保存ポリシーの効果を確認することをお薦めします。予想されるデータベース使用状況は、最大データベース使用率ではなく、以前のデータベース使用状況に基づいていることに注意してください。
レポータで使用可能なデフォルトのデータベース記憶域の量は500GBで、これはほとんどのデプロイでユーザーの操作要件を満たすものです。
例 - グループ数の増加
次の状況を考えてみましょう。情報を日、月、年の各レベルで90日間、24か月間、5年間保存し、失敗したページ、URLおよびサービスの情報は90日間保存することに決定しました。この例のためには、スイートは1種類しか構成されていません。このデータを保存するのに必要なデータベース記憶域の最大量は、表1-7に示すとおりです。
フル・セッション・リプレイ(FSR)機能を使用する場合、コレクタ・システムで使用可能な記憶容量の追加が必要になる可能性があります。これは、コレクタ・サーバーの既存のハード・ドライブのパーティションではなく、別のデバイスにし、RUEIファイル・システムにアクセスできるようにする必要があります。この手順は、記憶域の要件に関する指標とともに、この項の残りの部分で説明します。この手順は、フル・セッション・リプレイ情報が必要なコレクタごとに繰り返す必要があります。
フル・セッション・リプレイ用追加記憶域の構成
この後説明する手順は、完全に機能しているシステムがあり、FSRが有効になっていることを前提としています。追加の必須記憶域を構成するには、次のようにします。
デバイスをマウントします。たとえば、/mnt/external_storageの下にマウントします。
次のコマンドを発行して、一時的にコレクタを停止します。
appsensor stop wg
$APPSENSOR_HOME/wg/REPLAYディレクトリを新しいデバイスに移動します。上の例では、これは/mnt/external_storageで、その結果、リプレイ・ファイルは/mnt/external_storage/REPLAYディレクトリに置かれるようになります。
/mnt/external_storage/REPLAYから$APPSENSOR_HOME/wg/REPLAYへのシンボリック・リンクを作成します。
次のコマンドを発行して、コレクタを再起動します。
appsensor start wg
必須記憶域容量を計算します。これには、毎日の平均ページ・ビュー数に平均ページ・サイズを掛けます。次に、この数にフル・セッション・リプレイ・データの希望保存日数を掛けます。表1-8を指標として使用してください。
表1-8 フル・セッション・リプレイ記憶域の推定値
| データ量が小さいページ(10KBまで) | データ量が中程度のページ(50KBまで) | データ量が大きいページ(100KBまで) | ||||
|---|---|---|---|---|---|---|
|
1日当たりのページ・ビュー数(100万単位) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
|
0.5 |
5 |
0.1 |
25 |
0.3 |
50 |
0.6 |
|
2 |
20 |
0.2 |
100 |
1.2 |
200 |
2.3 |
|
5 |
50 |
0.6 |
250 |
2.9 |
500 |
5.8 |
|
10 |
100 |
1.2 |
500 |
5.8 |
1000 |
11.6 |
|
20 |
200 |
2.3 |
1000 |
11.6 |
2000 |
23.1 |
|
50 |
500 |
5.8 |
2500 |
28.9 |
5000 |
57.9 |
|
注意: FSR機能では、多数の非順次読込み操作が使用されることに注意してください。I/Oパフォーマンスを最適化する方法の情報は、ハードウェアのベンダーにお問合せください。 |
「構成」、「一般」、「詳細設定」、「コレクタ・データ保持ポリシー」の順に選択します。フル・セッション・リプレイ記憶域のサイズ(GB)設定をクリックします。必須記憶域のサイズを指定(GB単位)します。指定できる最大値は100TBです。次に、「保存」をクリックします。
RUEIインストールに必要なRAMの量を計算するとき、次の点を検討することをお薦めします。
構成された処理エンジンのないレポータ・システムまたは処理エンジン・システム自体で、1日当たり100万ビジター・セッションの場合、256MBが必要です。したがって、1日当たり300万ビジター・セッションの場合、768MBが必要になります。さらに、100万ページ・ビューごとに100MBから256MBが必要です。正確な量は、監視対象のURLの長さ、平均セッション持続時間およびイベント(カスタム・ディメンションなど)の数によって決まります。
各コレクタ・システムでは、100同時ヒットごとに2MB、1000件のSSL接続ごとに1MBが必要です。さらに、ネットワーク通信は、個々のTCPセッションが削除され始める前に、600MBpsまでバッファリングできます。コンテンツ・チェック(XPath問合せやエラー文字列など)用にも最大600MBpsを想定しておく必要があります。多数のコンテンツ・チェックを定義したり、コンテンツ・チェックにNLS文字セットを指定したりする場合、必要なメモリーが増える可能性があることに注意してください。
次のGNU/Linuxディストリビューションがサポートされています。
Oracle Linux 5.x 64ビットIntelまたはAMD互換性。
RedHat Enterprise Linux 5.x 64ビットIntelまたはAMD互換性。
機密データの暗号化
機密データの暗号化が必要な場合、Linuxのインストール手順におけるディスク・パーティションの段階で、ディスク構成全体を暗号化する機会があります。詳細は、次を参照してください。
すべてのサーバーのシステム・クロックを、UDPポート123を介してNTPを使用し、同期化。
TCPおよびUDPポート53でのDNS情報リクエストのサポート。
TCPポート25を使用したレポートおよび電子メール・アラートのサポート。
UDPポート161/162を使用したSNMPマネージャからのリクエストでのSNMPトラップのサポート。
RUEIユーザー・インタフェースが、HTTPSポート443を通じてアクセス可能であること。
リモート・データベース設定の場合、レポータとリモート・データベース・サーバー間でTCPポート1521へのアクセスが必要。
各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。他のすべてのポートはブロックすることをお薦めします。
フェイルオーバー・レポータ・システムを構成する場合は(第8章「フェイルオーバー・レポータ・システムの構成」で説明)、プライマリおよびセカンダリ・レポータ・システムがICMPを使用して相互通信可能でなければなりません。
フェイルオーバー・コレクタ・システムを構成する場合は(第9章「フェイルオーバー・コレクタ・システムの構成」で説明)、プライマリおよびセカンダリ・コレクタ・システムがICMPを使用して相互通信可能でなければなりません。
コレクタとレポータおよびコレクタと処理エンジンのバンド幅
リモート・コレクタとレポータ・システム間で転送されるデータ量は、主としてRUEIによって監視されるネットワーク・アプリケーション通信のタイプやレベルによって決まります。さらに、RUEIの構成(定義済の機能エラー、コンテンツ・チェック、ページ命名スキームなど)も、レポータ・システムに転送する必要のあるコレクタ・ファイルのサイズに影響を与えます。
ピーク時には、転送が必要なデータの量は、通信量の少ない期間より多くなります。リモート・コレクタからレポータ・システムへのデータ送信の正確な量は、実際のRUEIデプロイ後でなければ確認できません。
初期のデプロイには、次の簡単なルールを使用できます。1日のページ・ビュー500万件ごとに、ピーク時のピーク転送量は約125MB、1日当たり約1GBになります。したがって、通常、コレクタによって格納され、レポータに転送される通信は、実際に監視される通信の数パーセントにすぎません。このデータ転送量を最小限に抑える必要がある場合、RUEIで必要のない監視対象HTTP通信の量を最小限に抑えることをお薦めします。たとえば、サブネットまたはVLANフィルタ設定ネットワークを使用します。
処理エンジンを使用するデプロイメントの場合、上記の内容がコレクタと処理エンジン接続にも適用されます。
ファイアウォール要件
表1-9に、各RUEIデプロイメントのファイアウォール要件を示します。
表1-9 RUEIファイアウォール・ルール
| コピー元 | コピー先 | ポート | ソケット・タイプ | 必須 | 説明 |
|---|---|---|---|---|---|
|
レポータ |
コレクタ |
22 (SSH) |
TCP |
Y |
各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。 |
|
レポータ |
処理エンジン |
22 (SSH) |
TCP |
Y |
処理エンジン・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。 |
|
レポータ |
処理エンジン |
1521脚注1 (NET8) |
TCP |
Y |
各処理エンジン・システムは、データベース接続(デフォルトでは、ポート1521以上)からアクセスできる必要があります。 |
|
レポータ |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
処理エンジン |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
処理エンジン |
コレクタ |
22 (SSH) |
TCP |
Y |
各コレクタ・システムに、TCPポート22を介して処理エンジン・システムでアクセスできなければなりません。 |
|
処理エンジン |
レポータ |
1521 (NET8) |
TCP |
Y |
各処理エンジン・システムは、データベース接続(デフォルトでは、ポート1521以上)からアクセスできる必要があります。 |
|
コレクタ |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
Remote DB server |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
レポータ |
DNSサーバー |
53 (DNS) |
TCP/UDP |
N脚注2 |
DNS情報のリクエストをサポートします。 |
|
コレクタ |
DNSサーバー |
53 (DNS) |
TCP/UDP |
DNS情報のリクエストをサポートします。 |
|
|
Remote DB server |
DNSサーバー |
53 (DNS) |
TCP/UDP |
DNS情報のリクエストをサポートします。 |
|
|
レポータ |
メール・サーバー |
25 (SMTP) |
TCP |
N |
レポートと電子メールのリクエストをサポート。 |
|
レポータ |
SNMPマネージャ・サーバー |
161、162 (SNMP) |
UDP |
N |
SNMPマネージャからのリクエストでのSNMPトラップのサポート。 |
|
クライアント・ブラウザ |
レポータ |
443 (HTTPS) |
TCP |
Y |
RUEIユーザー・インタフェースが、HTTPSポートでアクセス可能であること。 |
脚注1 このポートが構成可能なことに注意してください。
脚注 2 オプションですが、強くお薦めします。
RUEIユーザー・インタフェースにアクセスするワークステーションには、次のいずれかのブラウザがインストールされている必要があります。
Mozilla Firefox 3.6(以上)。
Internet Explorer 7、8または9。
Safari 4および5。
Google Chrome 17(以上)。
JavaScriptは有効にする必要があります。その他に必要なブラウザ・プラグインはありません。
また、ワークステーションの画面解像度は、1024×768(以上)が必要です。
|
重要: ブラウザ内のポップアップ・ブロッカが無効になっていることを確認してください。 |
AJAXサポート
RUEIではAJAXを使用して、ユーザーとの対話を強化します。Internet Explorerでは、MSXML制御を利用してAJAXの操作を容易にします。AJAXに依存すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。
Internet Explorer 6では、PNG形式での透過的なイメージが正常にサポートされません。RUEIは、この問題に対して、DirectXに依存するよく知られた解決策(AlphaImageLoader)を使用します。IE6でブラウザ・クラッシュが発生した場合、使用しているDirectXのバージョンを更新する必要がある可能性があります。PNGの解決策を実行すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。
脚注の説明
脚注1: コピー・ポートは、スイッチ・ポート・アナライザ(SPAN)・ポートとしても知られる、Ciscoスイッチの機能です。
