ヘッダーをスキップ
Oracle® Real User Experience Insightインストレーション・ガイド
リリース11.1 for Linux x86-64
B63040-01
  目次
目次		 索引
索引
戻る
前へ 		 次へ
次へ		  

1 スタート・ガイド

この章では、Oracle Real User Experience Insight(RUEI)の役割、アーキテクチャ、接続およびデプロイ・オプションについて紹介します。

RUEIとは

Webアプリケーションおよびサービスの利用は増え続けています。これには、マーケティング手段としてのインターネットの利用だけでなく、エクストラネットベースのサプライ・チェーンやバックオフィス統合、内部アプリケーションのイントラネット・デプロイも含まれます。明確に定義されたビジネス機能を実装したWebサービスの利用もますます増えています。RUEIは、これらすべてのデプロイ・シナリオの可用性およびパフォーマンスの測定、分析、改善のために設計されています。

データ収集

通常、RUEIはWebサーバーの前、DMZ内のファイアウォールの後ろにインストールされます(図1-1)。データ収集方法は、ネットワーク・プロトコル分析(NPA)テクノロジに基づいています。この方法は100%非侵入的です。したがって、Webサーバーには負荷はかからず、パフォーマンスに影響を与えるソフトウェア・エージェントをインストールする必要もありません。さらに、現行のアプリケーションまたはインフラストラクチャに変更を加える必要もありません。アプリケーションの新リリースがデプロイされた場合、またはWebサーバーが増設された場合にも、RUEIの監視環境に対する変更はまったく、またはほとんど必要ありません。

図1-1 RUEIでのデータの収集方法

図1-1の説明が続きます
「図1-1 RUEIでのデータの収集方法」の説明

ビジターがオブジェクトをリクエストすると、RUEIではそのリクエストを確認し、リクエストされたオブジェクトをビジターに示すまでにWebサーバーで要する時間を測定します。この時点で、誰がそのページをリクエストしたか(クライアントIP)、どのオブジェクトがリクエストされたか、およびどのサーバーからオブジェクトが要求されたか(サーバーIP)がRUEIで認識されています。

RUEIでは、Webサーバーが応答し、リクエストされたオブジェクトをビジターに送信するときに、そのレスポンスを確認します。この時点で、サーバーからのレスポンスがあるかどうか、このレスポンスが正しいかどうか、リクエストされたオブジェクトの生成にWebサーバーで要する時間、およびオブジェクトのサイズを確認できます。さらに、オブジェクトがビジターに完全に受信されたかどうか、またはビジターがダウンロードを中断したかどうか(つまり、配信の証明)も確認できます。したがって、RUEIでは、オブジェクトがインターネットからビジターに渡るまでの時間を測定し、ビジターとサーバー間のインターネット・スループット(すなわち、ビジターの接続速度)を計算できます。

製品アーキテクチャ

RUEIは、図1-2に示すように、3つのレイヤーからなる製品アーキテクチャに基づいています。

図1-2 RUEIの製品アーキテクチャ

図1-2の説明が続きます
「図1-2 RUEIの製品アーキテクチャ」の説明

監視対象のパケットは、次のレイヤーで処理されます。

  • データ収集

    このレイヤーは、RAWデータの取得とデータ・プロセッサへの配信を担当します。このデータは、複数のソースから収集できます。使用可能な接続オプションについては、この項で後述します。

  • データ処理

    このレイヤーでは、RAWデータがOLAPデータ・セットに変換されます。これは多次元データ構造を構成し、データ・ブラウザ内で表示できます。

  • データ・プレゼンテーション(レポータ)

    このレイヤーは、RUEIの分析およびレポート作成環境です。これは、Webベースの情報ポータルで、選択した任意のブラウザからアクセスできます。データ処理とデータ・プレゼンテーション・レイヤー間のインタフェースは、オープン・データベース・コールに基づいています。

セキュリティ

HTTP(S)データ・ストリームを読み取るために、専用のソフトウェア・モジュールでTCP/IPパケット・ストリームを再アセンブルします。データ・コレクタにIP番号が割り当てられていないことと、これらのデータ・コレクタを使用するソフトウェアに機能的なIPスタックがないことから、RUEIではデータ・コレクタで受信される受信トラフィックに応答できません。これにより、RUEIは監視対象のネットワークから見えなくなり、完全にセキュアになります。


注意:

RUEIでは非侵入的な方法でデータを収集するため、測定ポートでエラーが発生しても、再転送のリクエストはできません。

暗号化データを記録するようにデータ収集を設定できます。このために、WebサーバーのプライベートSSLキーのコピーをデータ・コレクタ内でセットアップする必要があります。さらに、フォームまたはコンテンツのPOSTリクエスト内の引数の機密データのログを除外するようにRUEIを設定できます。これは、データ・マスキング(またはブラインディング)と呼ばれています。

接続オプション

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-3の説明が続きます。
「図1-3 コピー・ポートを使用したネットワーク接続」の説明

図1-3の下の部分に示した構成では、コレクタはブラウザが送信するすべてのパケットのコピーを受信するように構成されているポートに接続されています。このポートをコピー・ポートと呼びます。コピー・ポートは、任意またはすべてのデータ・ポートからの通信を1つの未使用ポートにコピーでき、ポート上での双方向の通信を防いで、ネットワークに通信が逆流しないように保護します。

スイッチ上でコピー・ポートをアクティブ化するとパフォーマンスに影響する可能性がある点に注意してください。通常、コピー・ポートでは広範な構成オプションがサポートされていますが、これらのオプションの詳細は、使用しているスイッチのドキュメントを参照するか、ベンダーにお問い合せください。

TAP

TAPは、任意の2つのネットワーク・デバイス(ルータやファイアウォールなど)の間に配置できます。TAPに接続されたすべての監視デバイスは、すべてのエラーも含めて、インラインであるかのように同じ通信を受信します。これは、TAPでリンク上のすべての通信を複製し、それを監視ポートに転送することにより実現します。図1-4の例は、1つのコレクタに対する典型的なTAPのデプロイを示しています。

図1-4 TAPを使用したネットワーク監視

図1-4の説明が続きます。
「図1-4 TAPを使用したネットワーク監視」の説明

重要:

コピー・ポートと異なり、TAPでは停電の場合にも、引き続きネットワーク・デバイス間でデータが流れます。また、コピー・ポートは負荷がかかったとき、パケットが失われやすくなります。TAPデバイスは、銅回線またはファイバ・ベースのインフラストラクチャに使用できます。さらに、必要な時と場所に簡単にデプロイでき、しかもスイッチの再構成や、ネットワーク・リンクのケーブル再配線に必要なエンジニアも必要ありません。これらの理由で、コピー・ポートよりもTAPの使用を強くお薦めします。

概して、TAPには、ネットワークTAP、再生成TAPおよび集約TAPの3タイプがあります。RUEIでは、ネットワークTAPと再生成TAPの使用がサポートされています。アグリゲーションTAPは、データが失われる可能性があり、許容レベルの正確さを提供できないため、お薦めできません。ただし、複数のコレクタのデプロイ、または1つのコレクタへの複数リンクの直接接続を、複数のストリームからのデータの集約に使用できます。また、ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。

インストールおよびデプロイメントのオプション

RUEIシステムは、レポータとして、またはコレクタとしての2つの異なる方法で構成できます。各インストール・オプションについては、この後の項で説明します。

レポータ

この場合、レポータは収集データに対するブラウザベースのインタフェースとなります。処理後、このデータはOracleデータベースに格納されます。このデータベースは、ローカル(つまり、レポータ・システム上)に置くことも、リモート・データベース・サーバーに置くこともできます。

各レポータ・インストールには、ローカルのコレクタ・インスタンスも含まれていることに注意してください。レポータは、このローカル・コレクタによって収集された情報のみを処理するように構成する(図1-5に示したような単一サーバー構成)ことも、追加のコレクタ・インストールからの情報を受信するように構成する(オプション)こともできます。レポータ・システム上のローカルのコレクタ・インスタンスは、必要なければ無効にすることもできます。

コレクタ

RUEIシステムがコレクタとしてインストールされている場合、収集されたデータはレポータ・システムに送信されます。複数のコレクタを同じレポータに接続することができます。図1-5の分割サーバー#1は、単一コレクタの分割サーバー構成の例であり、分割サーバー#2は、2つのコレクタを使用した分割サーバー構成の例です。コレクタ・システムとレポータ・システムの間には、直接ネットワーク接続が必要であることに注意してください。

図1-5 構成オプション

図1-5の説明が続きます。
「図1-5 構成オプション」の説明

ローカルおよびリポートのデータベース・インストール

前述のように、レポータ・システムを介して入手可能なデータは、Oracleデータベースに格納されます。このデータベースは、ローカルのレポータ・システムに置くことも、リモート・データベース・サーバー(データベース・クラスタなど)に置くこともできます。

リモート・データベース・サーバーを使用すると、ローカルにインストールされたデータベースより潜在的に多くの利点があります。特に、既存のセキュリティおよびバックアップのポリシーと統合しやすく、さらに専用サーバーの使用によりパフォーマンスが向上します。

現在、RUEI 11.1はOracle 11gデータベースをサポートしています。11gR1の手順を説明しますが、11gR2もサポートしています。Oracle 10g(またはそれ以前の)データベースはサポートされていない点に注意してください。

スケーラビリティのオプション

非常に高レベルのデータ通信を監視する必要がある場合、複数のコレクタの使用を検討できます。さらに、このデプロイにより、セキュリティが強化される可能性もあります。たとえば、コレクタをオフィス・ネットワーク外に配置する一方で、レポータ・システムをネットワーク内に配置する方法です。

図1-5の分割サーバー構成#1は、典型的なDMZインストールの例を示しています。コレクタはDMZにあり、レポータはサーバー・ネットワーク環境内にあります。ローカル・コレクタ・インスタンスは無効であることに注意してください。分割サーバー構成#2は、2つのコレクタで構成されているデプロイの例を示しています。たとえば、これは2つのデータ・センター(どちらもDMZを監視)間で使用できます。ここでは、一方のデータ・センターが、他方のフェイルオーバーとして機能します。

分割サーバー構成#3は、両方のデータ回線が同じレポート作成環境で監視されるデプロイメントの例を示しています。ここでは別のサーバー上のデータベースへのオフロードの使用も示しています。このデプロイメントは、各回線上の通信が互いに排他的であることを前提としていることに注意してください。セキュリティ上の理由で使用されるデプロイメントの例も示しています。WebサーバーAおよびBからの通信が監視され、レポートが作成されるのに対し、WebサーバーCからの通信は監視もレポート作成も行われません。これは、コレクタがスイッチの上に配置されていない理由でもあります。

セキュリティ上の理由から、レポータ・システムに対するアクセスは、信頼できるIPの範囲に制限することをお薦めします。同様に、レポータ・システムを内部ネットワークに配置して、セキュリティを最大限にすることができます。コレクタのデータ収集ポートはDMZ内に置く必要があります。

ハードウェア要件

選択した構成(「インストールおよびデプロイのオプション」で説明)に必要な最低限のシステム仕様については、この後の項で説明しています。

ネットワーク・カード

インフラストラクチャ用のネットワーク・カードの選択は、慎重に検討することをお薦めします。「接続オプション」で選択した接続オプションによっては、銅回線ベースおよびファイバベースの両方のネットワーク・カードが必要な場合があります。必要に応じて、ネットワークおよびシステムの両方の管理チームに相談してください。


注意:

必須および推奨のシステム仕様の詳細は、Oracleサポート・サービスにお問い合せください。

単一サーバーの要件

表1-1 単一サーバー・システムの最低要件

要素 要件

CPU

64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。

メモリー

16GB。

ディスク領域

400GB以上のHDD空き領域。脚注1 、脚注2 

ネットワーク・インタフェース

ネットワークTAPデバイスを使用する場合は脚注3 、3つ以上のネットワーク・インタフェースが必要。

  • ネットワーク通信取得用のインタフェースが2つ。

  • ネットワーク・サービス用のインタフェースが1つ。

GSMモデム(オプション)

テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート(ttyUSB0)を使用します。テキスト・メッセージ送信の代替方法を使用できます(http/e-mail)。

脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-5、RAID-10または同等の記憶域構成を強くお薦めします。

脚注2 データ交換機能が強化されている場合は、増やす必要があります。

脚注3 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。

レポータの要件

表1-2 レポータ・システムの最低要件

要素 要件

CPU

64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。

メモリー

16GB。

ディスク領域

400GB以上のHDD空き領域脚注1 、脚注2 

ネットワーク・インタフェース

1つ以上のネットワーク・インタフェースが必要。

GSMモデム(オプション)

テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート(ttyUSB0)を使用します。テキスト・メッセージ送信の代替方法を使用できます(http/e-mail)。

脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-5、RAID-10または同等の記憶域構成を強くお薦めします。

脚注2 データ交換機能が強化されている場合は、増やす必要があります。

コレクタの要件

コレクタ・システムの要件を表1-3に示します。

表1-3 コレクタ・システムの最低要件

要素 要件

CPU

64ビットIntelまたはAMDデュアルコア・プロセッサまたは同等のもの。

メモリー

8GB。

ディスク領域

200GB以上のHDD空き領域。

ネットワーク・インタフェース

ネットワークTAPデバイスを使用する場合は脚注1 、3つ以上のネットワーク・インタフェースが必要。

  • ネットワーク通信取得用のインタフェースが2つ脚注2 。

  • レポータ・システムとの通信用のインタフェースが1つ。

ネットワーク・コピー・ポートを使用する場合、2つ以上のネットワーク・インタフェースが必要。

  • ネットワーク通信取得用のインタフェースが1つ。

  • レポータ・システムとの通信用のインタフェースが1つ。

脚注1 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成は使用できません。

脚注2 アップストリーム通信およびダウンストリーム通信用。アップストリームとダウンストリームの通信を1つの回線に統合するTAPの使用はお薦めできません。


重要:

Intel(またIntelと互換性のある)64ビット・プラットフォームは、すべてのデプロイメント・シナリオにおけるハードウェアとオペレーティング・システムでの必須要件です。

デプロイのベスト・プラクティス

この項では、RUEIのデプロイメントを最適化するベスト・プラクティス・フレームワークを紹介します。次の情報を注意深く再検討することをお薦めします。

デプロイの計画

RUEIデプロイメント計画を決定する前に、監視対象のネットワーク環境の性質を明確に理解することが重要です。これには、基本的なネットワーク接続性、ポート、アドレス指定および物理デバイス要件だけではなく、監視対象のアプリケーションのしっかりした理解も含まれます。

さらに、RUEIをデプロイする前に、ネットワーク内の基本的な通信フローが確認されている必要があります。これには、平均およびピーク時の通信量に関する情報が必要です。物理デプロイ要件(スペースの制限、距離、電力計画、ラックのスペースおよびレイアウト、または配線など)も確認されている必要があります。

付録F「インストール・チェックリスト」で紹介しているチェックリストを使用すれば、この情報の大部分を取得できます。

Formsベースの通信

Formsベースの通信を監視する場合、メモリー要件は、「ハードウェア要件」 に概説されているものよりも大きくなる可能性があることに注意してください。特に大量のForms通信を伴うデプロイの場合がこれに当てはまります。この場合は、分割サーバーのデプロイを検討する必要があります。

フル・セッション・リプレイ機能

フル・セッション・リプレイ機能を利用する場合は、記憶容量追加の構成が必要になる可能性があります。これについては、「フル・セッション・リプレイの記憶域要件」で説明しています。

暗号化通信

監視対象の通信の相当な量が暗号化される場合、CPUのオーバーヘッドが増える可能性があります。この場合、CPUの追加または分割サーバー・デプロイの構成を検討することをお薦めします。

大量の通信

非常に多い量の(つまり、1日当たりのページ・ビューが1000万件を超える)通信を監視している場合、分割サーバー・デプロイを検討する必要があります。または、リモート・データベースの使用を検討してください。後者には、レポート・システム上のCPUオーバーヘッドを大幅に(最大30%)減らす効果があります。監視対象環境の1日当たりのページ・ビューが2000万件を超える場合、分割サーバー・デプロイとリモート・データベースの両方の使用を検討する必要があります。

データ保存ポリシー

『Oracle Real User Experience Insightユーザーズ・ガイド』で説明されているように、データ・ブラウザ内での特定データの可用性は、そのデータに基づくレポートと同様に、RUEIインストールに定義されたレポータ・データ保存ポリシーによって決まります。デフォルトでは、RUEIには情報が日、月、年の各レベルで32日、13か月および5年間保存されます。さらに、失敗したページ、URLおよびサービスに関する情報は、15日間保存されます。デフォルトのデータ保存ポリシーを維持するために必要なデータベース記憶域の最大量は、表1-4に示すとおりです。

表1-4 デフォルトの必須データベース記憶域

保存データの種類 デフォルトの保存ポリシー 期間当たりに必要なDB領域(GB) 合計必須DB領域(GB)

失敗したページ/URL/サービス

15

1.5

22.5

日脚注1 

32

1

32

月

13

1

13

年

5

1

5




スイート脚注2 

15

0.5脚注3 

7.5




追加のオーバーヘッド

10




合計必須DB領域

90

脚注1 これには、All pages、All sessions、All functions、All transactions、Key pagesおよびURLの診断グループがあります。

脚注2 スイートでは、日の保存ポリシー設定が使用されます。

脚注3 構成されたスイートの種類ごとに、1日当たり0.5GBが必要です。

保存されるデータの種類ごとに必要なデータベース記憶域に加えて、他の目的のためにそれ相応の10GBのデータベース記憶域が必要であることに注意してください。これにはKPI、SLAおよび処理要件が含まれます。表1-4では、1種類のスイートが構成されていることを想定しています。

デフォルトのレポータ・データ保存ポリシーを変更する場合、Calculate機能を使用して、必須データベース記憶域に対する新しい保存ポリシーの効果を確認することをお薦めします。予想されるデータベース使用状況は、最大データベース使用率ではなく、以前のデータベース使用状況に基づいていることに注意してください。

レポータで使用可能なデフォルトのデータベース記憶域の量は200GBで、これはほとんどのデプロイでユーザーの操作要件を満たすものです。

例 - グループ数の増加

次の状況を考えてみましょう。情報を日、月、年の各レベルで90日間、24か月間、5年間保存し、失敗したページ、URLおよびサービスの情報は90日間保存することに決定しました。この例のためには、スイートは1種類しか構成されていません。このデータを保存するのに必要なデータベース記憶域の最大量は、表1-5に示すとおりです。

表1-5 必須データベース記憶域

保存データの種類 デフォルトの保存ポリシー 期間当たりに必要なDB領域(GB) 合計必須DB領域(GB)

失敗したページ/URL/サービス

90

1.5

135

日

90

1

90

月

24

1

24

年

5

1

5




スイート

90

0.5

45




追加のオーバーヘッド

10




合計必須DB領域

264

最大データ・ブラウザ・グループ・サイズ

データ保存ポリシー設定の変更の他に、データが圧縮されるまで、データベース・ブラウザ・グループを大きくできる最大サイズも変更できます。これについては、以下で詳しく説明しています。

フル・セッション・リプレイ記憶域要件

フル・セッション・リプレイ機能を使用する場合、コレクタ・システムで使用可能な記憶容量の追加が必要になる可能性があります。これは、コレクタ・サーバーの既存のハード・ドライブのパーティションではなく、別のデバイスにし、RUEIファイル・システムにアクセスできるようにする必要があります。この手順は、記憶域の要件に関する指標とともに、この項の残りの部分で説明します。この手順は、フル・セッション・リプレイ情報が必要なコレクタごとに繰り返す必要があります。

フル・セッション・リプレイ用追加記憶域の構成

追加の必須記憶域を構成するには、次のようにします。

  1. デバイスをマウントします。たとえば、/mnt/external_storageの下にマウントします。

  2. 次のコマンドを発行して、一時的にコレクタを停止します。

    appsensor stop wg

  3. $APPSENSOR_HOME/wg/REPLAYディレクトリを新しいデバイスに移動します。上の例では、これは/mnt/external_storageで、その結果、リプレイ・ファイルは/mnt/external_storage/REPLAYディレクトリに置かれるようになります。

  4. /mnt/external_storage/REPLAYから$APPSENSOR_HOME/wg/REPLAYへのシンボリック・リンクを作成します。

  5. 次のコマンドを発行して、コレクタを再起動します。

    appsensor start wg

  6. 必須記憶域容量を計算します。これには、毎日の平均ページ・ビュー数に平均ページ・サイズを掛けます。次に、この数にフル・セッション・リプレイ・データの希望保存日数を掛けます。表1-6を指標として使用してください。

    表1-6 フル・セッション・リプレイ記憶域の推定値


    		 データ量が小さいページ(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


    重要:

    表1-6は、単なる指標です。平均のページ・サイズおよび1日のページ・ビュー数を定期的に調べ、必要に応じて必須記憶域サイズを調整することを強くお薦めします。


    注意:

    FSR機能では、多数の非順次読込み操作が使用されることに注意してください。I/Oパフォーマンスを最適化する方法の情報は、ハードウェアのベンダーにお問合せください。

  7. Configuration、General、Advanced settings、Collector data retention policyの順に選択します。Full session replay storage size (GB)設定をクリックします。必須記憶域のサイズを指定(GB単位)します。指定できる最大値は100TBです。準備ができたら、Saveをクリックします。

メモリー要件

RUEIインストールに必要なRAMの量を計算するとき、次の点を検討することをお薦めします。

  • レポータ・システムでは、1日当たり100万ビジター・セッションごとに256MBが必要です。したがって、1日当たり300万ビジター・セッションの場合、768MBが必要になります。さらに、100万ページ・ビューごとに100MBから256MBが必要です。正確な量は、監視対象のURLの長さ、平均セッション持続時間およびイベント(カスタム・ディメンションなど)の数によって決まります。

  • 各コレクタ・システムでは、1万ヒットごとに200MB、1000件のSSL接続ごとに1MBが必要です。さらに、ネットワーク通信は、個々のTCPセッションが削除され始める前に、600MBまでバッファリングできます。コンテンツ・チェック(XPath問合せやエラー文字列など)用にも最大600MBを想定しておく必要があります。多数のコンテンツ・チェックを定義したり、コンテンツ・チェックにNLSキャラクタ・セットを指定したりする場合、必要なメモリーが増える可能性があることに注意してください。

ソフトウェア要件

次のGNU/Linuxディストリビューションがサポートされています。

機密データの暗号化

機密データの暗号化が必要な場合、Linuxのインストール手順におけるディスク・パーティションの段階で、ディスク構成全体を暗号化する機会があります。詳細は、以下を参照してください。

ネットワーク要件

コレクタとレポータ間のバンド幅

リモート・コレクタとレポータ・システム間で転送されるデータ量は、主としてRUEIによって監視されるネットワーク・アプリケーション通信のタイプやレベルによって決まります。さらに、RUEIの構成(定義済の機能エラー、コンテンツ・チェック、ページ命名スキームなど)も、レポータ・システムに転送する必要のあるコレクタ・ファイルのサイズに影響を与えます。

ピーク時には、転送が必要なデータの量は、通信量の少ない期間より多くなります。リモート・コレクタからレポータ・システムへのデータ送信の正確な量は、実際のRUEIデプロイ後でなければ確認できません。

初期のデプロイには、次の簡単なルールを使用できます。1日のページ・ビュー500万件ごとに、ピーク時のピーク転送量は約125MB、1日当たり約1GBになります。したがって、通常、コレクタによって格納され、レポータに転送される通信は、実際に監視される通信の数パーセントにすぎません。このデータ転送量を最小限に抑える必要がある場合、RUEIで必要のない監視対象HTTP通信の量を最小限に抑えることをお薦めします。たとえば、サブネットまたはVLANフィルタ設定ネットワークを使用します。

ファイアウォール要件

表1-7に、各RUEIデプロイメントのファイアウォール要件を示します。

表1-7 RUEIファイアウォール・ルール

送信元 宛先 ポート ソケット・タイプ 必須 説明

レポータ

コレクタ

22 (SSH)

TCP

Y

各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。

レポータ

NTPサーバー

123 (NTP)

UDP

Y

All server system clocks must be synchronized via NTP.

コレクタ

NTPサーバー

123 (NTP)

UDP

Y

All server system clocks must be synchronized via NTP.

Remote DB server

NTPサーバー

123 (NTP)

UDP

Y

All server system clocks must be synchronized via NTP.

レポータ

DNSサーバー

53 (DNS)

TCP/UDP

N脚注1 

Support DNS information requests.

コレクタ

DNSサーバー

53 (DNS)

TCP/UDP

NFootref 1

Support DNS information requests.

Remote DB server

DNSサーバー

53 (DNS)

TCP/UDP

NFootref 1

Support DNS information requests.

レポータ

メール・サーバー

25 (SMTP)

TCP

N

レポートと電子メールのリクエストをサポート。

レポータ

SNMPマネージャ・サーバー

161、162 (SNMP)

UDP

N

SNMPマネージャからのリクエストでのSNMPトラップのサポート。

クライアント・ブラウザ

レポータ

443 (HTTPS)

TCP

Y

RUEIユーザー・インタフェースが、HTTPSポートでアクセス可能であること。

Footnote 1 オプションですが、強くお薦めします。

クライアント要件

RUEIユーザー・インタフェースにアクセスするワークステーションには、次のいずれかのブラウザがインストールされている必要があります。

JavaScriptは有効にする必要があります。その他に必要なブラウザ・プラグインはありません。

また、ワークステーションの画面解像度は、1024×768(以上)が必要です。


重要:

ブラウザ内のポップアップ・ブロッカが無効になっていることを確認してください。

AJAXサポート

RUEIではAJAXを使用して、ユーザーとの対話を強化します。Internet Explorerでは、MSXML制御を利用してAJAXの操作を容易にします。AJAXに依存すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。

Internet Explorer 6では、PNG形式での透過的なイメージが正常にサポートされません。RUEIは、この問題に対して、DirectXに依存するよく知られた解決策(AlphaImageLoader)を使用します。IE6でブラウザ・クラッシュが発生した場合、使用しているDirectXのバージョンを更新する必要がある可能性があります。PNGの解決策を実行すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。


脚注の説明

脚注1: コピー・ポートは、スイッチ・ポート・アナライザ(SPAN)・ポートとしても知られる、Ciscoスイッチの機能です。
脚注2: テスト・アクセス・ポート(TAP)・デバイスは、NetOptics社などの専門ベンダーが提供しています。
  戻る
前へ 		 次へ
次へ
  目次
目次		 索引
索引