1 Getting Started

This chapter introduces the role of Oracle Real User Experience Insight (or RUEI for short), its architecture, attachment, and deployment options.

1.1 What is RUEI?

The usage of Web applications and services continues to grow. This includes not only the use of the Internet as a marketing channel, but also Extranet-based supply chain and back-office integration, and Intranet deployment of internal applications. Increasingly, it also includes the utilization of Web services which implement clearly defined business functions. RUEI is designed for measuring, analyzing, and improving the availability and performance of all of these deployment scenarios.

1.1.1 Data Collection

Typically, RUEI is installed before the Web servers, behind a firewall in the DMZ (as shown in Figure 1-1). The data collection method is based on Network Protocol Analysis (NPA) technology. This method is 100% non-intrusive. Hence, it does not place any load on a Web server, or require installing software agents that will impact performance. In addition, it does not require any change to the current application or infrastructure. When a new application release is deployed, or when an additional Web server is added, there is no or very little change required to RUEI's monitoring environment.

Figure 1-1 How RUEI Collects Data

Description of "Figure 1-1 How RUEI Collects Data"

When an object is requested by a visitor, RUEI sees the request and measures the time the Web server requires to present the visitor with the requested object. At this point, RUEI knows who requested the page (the client IP), which object was requested, and from which server the object was requested (server IP).

When the Web server responds and sends the requested object to the visitor, RUEI sees that response. At this point, RUEI can see whether there is a response from the server, whether this response is correct, how much time the Web server required to generate the requested object, and the size of the object. In addition, RUEI can also see whether the object was completely received by the visitor, or if the visitor aborted the download (that is, proof of delivery). Hence, RUEI can determine the time taken for the object to traverse the Internet to the visitor, and calculate the Internet throughput between the visitor and the server (that is, the connection speed of the visitor).

1.1.2 Product Architecture

RUEI is based on a three-layer product architecture, as shown in Figure 1-2:

Figure 1-2 RUEI Product Architecture

Description of "Figure 1-2 RUEI Product Architecture"

The monitored data packets are processed by the following layers:

Data collection

This layer is responsible for acquiring raw data and delivering it to the Data processor. This data can be collected from multiple sources. The available attachment options are described later in this section.
Data processing

This layer converts the raw data into OLAP data sets. These comprise the multidimensional data structure that is viewable within the data browser.
Data presentation (reporter)

This layer is RUEI's analysis and reporting environment. This is a Web-based information portal that can be accessed from any selected browser. The interface between the data processing and data presentation layer is based on open db calls.

1.2 Security

To read HTTP(S) data streams, a proprietary software module reassembles TCP/IP packet streams. Because the data collectors do not have an assigned IP number, and the software using these data collectors does not have a functional IP stack, RUEI is not able to respond to incoming traffic received on the data collectors. This makes RUEI "invisible" to the monitored networks, and completely secure.

Note:

Because of the non-intrusive way in which RUEI collects data, it is not possible for it to request retransmission in the event of an error on the measurement port.

Data collection can be configured to log encrypted data. To facilitate this, a copy of the Web server's private SSL keys needs to be set up in the data collector. In addition, RUEI can be configured to omit logging of sensitive data in the arguments of POST requests of forms or content; so called data masking (or blinding).

1.3 Connection Options

RUEI supports the use of both copy ports^Foot 1 and TAPs^Foot 2 for monitoring network traffic. Copy ports and TAPs are available for copper or fibre-based network infrastructures. While both devices allow non-intrusive monitoring of network traffic, there are differences between these two connection options. These are highlighted in the rest of this section.

1.3.1 Copy Ports

A copy port is a switch that starts to build up a Layer 2 forwarding table on the basis of the source MAC address of the different packets that the switch receives. After this forwarding table is built, the switch forward traffic that is destined for a MAC address directly to the corresponding port.

For example, after the Web server MAC in Figure 1-3 is learned, unicast traffic from the browser to the Web server is only forwarded to the Web server port. Therefore, the Collector does not see this traffic.

Figure 1-3 Network Connection Using a Copy Port

Description of "Figure 1-3 Network Connection Using a Copy Port"

In the configuration shown in the lower part of Figure 1-3, the Collector is attached to a port that is configured to receive a copy of every packet that the browser sends. This port is called a copy port. Copy ports can copy traffic from any or all data ports to a single unused port and prevents bi-directional traffic on the port to protect against backflow or traffic into the network.

Be aware that activating a copy port on a switch can have a performance impact. Typically, copy ports support a wide range of configuration options, and for further information about these options you should consult your switch documentation or contact the vendor.

1.3.2 TAPs

TAPs can be placed between any two network devices (such as routers and firewalls). Any monitoring device connected to a TAP receives the same traffic as if it were in-line, including all errors. This is achieved through the TAP duplicating all traffic on the link, and forwarding it to the monitoring port(s). The example shown in Figure 1-4 illustrates a typical TAP deployment for one Collector.

Figure 1-4 Network Monitoring Using a TAP

Description of "Figure 1-4 Network Monitoring Using a TAP"

Unlike copy ports, in the event of power failure, TAPs continue to allow data to flow between network devices. TAP devices are available for copper or fibre-based infrastructures. Generally, the use of TAPs is considered preferable since they can be easily deployed when and where required, but engineers do need to re-cable a network link.

Note:

Broadly speaking, there are three types of TAPs: network, regeneration, and aggregation TAPs. RUEI supports the use of network and regeneration TAPs. The use of aggregation TAPs is not supported. However, the deployment of multiple Collectors, or the connection of multiple links directly to one Collector, is available for the aggregation of data from multiple streams. In addition, be aware that when capturing data with a network-tap device, the use of cascaded-tap configurations is not supported.

1.4 Installation and Deployment Options

A RUEI system can be configured in two different ways: as a Reporter, or as a Collector. Each installation option is reviewed in the following sections.

Reporter

This is the standard installation option, and is the simplest to install and configure. Here, the Reporter provides a browser-based interface to the collected data. Note that each Reporter installation also contains a local Collector instance. The Reporter can either be configured to just process information gathered by this local Collector (this is a single-server configuration similar to the one shown in Figure 1-5), or can (optionally) be configured to receive information from additional Collector installations.
Collector

If a RUEI system is installed as a Collector, it submits the data it gathers to a Reporter system. Multiple Collectors can be attached to the same Reporter. Configuration #1 in Figure 1-5 is an example of a single Collector split-server configuration, while Configuration #2 is an example of a split-server configuration using two Collectors. Note that a direct network connection is required between the Collector(s) systems and the Reporter system.

Figure 1-5 Configuration Options

Description of "Figure 1-5 Configuration Options"

1.4.1 Scalability Options

The use of multiple Collectors may be considered when there is a need to monitor very high levels of data traffic. In addition, this deployment also provides the possibility of enhanced security. For example, by placing the Collector(s) outside the office network, while placing the Reporter system within the network.

Split-server configuration #1 in Figure 1-5 shows an example of a typical DMZ installation. The Collector is located in the DMZ, and the Reporter is within the server network environment. Note that the local Collector instance is disabled. Split-server configuration #2 shows an example of a deployment consisting of two Collectors. This could, for example, be used between two data centers (both monitoring the DMZ), where one data center acts as a failover for the other.

Split-server configuration #3 shows an example of a deployment in which both data lines are monitored in the same reporting environment. Note that this deployment assumes that the traffic on each line is mutually exclusive. It also shows an example of a deployment used for security reasons. While the traffic from Web servers A and B are monitored and reported, the traffic from Web server C is not. This is also the reason why the Collectors are not placed above the switch.

For security reasons, it is recommended that access. Similarly, you may want to locate the Reporter system inside the internal network to maximize its security. The Collector's data gathering ports should be in the DMZ.

1.5 Hardware Requirements

The required minimum system specifications for the selected configuration (as explained in Section 1.4) are described in the following sections.

Network Cards

It is recommended that you carefully consider the selection of network cards for your infrastructure. Depending on the connection option you selected in Section 1.3, "Connection Options", both copper and fibre-based network cards may be required. If necessary, consult both your network and systems management teams.

Note:

For more information about required and recommended system specifications, please contact Customer Support.

1.5.1 Single-Server Requirements

Table 1-1 Single-Server System Requirements

Element	Requirements
CPU	64-bit Intel or ADM dual-CPU, dual-core processor (> 2 G Hz) or equivalent.
Memory	16 GB.
Disk space	Minimum 400 GB HDD free space.^Foot 1^,^Foot 2
Network interfaces	When using a network-tap device^Foot 3, a minimum of three network interfaces is required: Two interfaces for network traffic capturing. One interface for network services.
GSM modem (optional)	Optional support for a GSM modem to send SMS messages. The modem needs to be either GSM07.05 or GSM07.07 compatible. It can be connected through a serial or USB port. If USB is used, RUEI uses the first available port (ttyUSB0). Alternative methods of sending SMS messages are available (http/e-mail).

^Footnote 1The Reporter servers require high performance data storage. (Hardware) RAID-5, RAID-10, or equivalent storage configurations with high performance disks are strongly recommended.

^Footnote 2This may be need to be increased if Enriched data exchange is enabled.

^Footnote 3When capturing data with a network-tap device, the use of cascaded tap configurations is not supported.

1.5.2 Reporter Requirements

Table 1-2 Reporter System Requirements

Element	Requirements
CPU	64-bit Intel or ADM dual-CPU, dual-core processor (> 2 G Hz) or equivalent.
Memory	16 GB.
Disk space	Minimum 400 GB HDD free space^Foot 1^,^Foot 2.
Network interfaces	A minimum of 1 network interface is required.
GSM modem (optional)	Optional support for a GSM modem to send SMS messages. The modem needs to be either GSM07.05 or GSM07.07 compatible. It can be connected through a serial or USB port. If USB is used, RUEI uses the first available port (ttyUSB0). Alternative methods of sending SMS messages are available (http/e-mail).

^Footnote 1The Reporter servers require high performance data storage. (Hardware) RAID-5, RAID-10, or equivalent storage configurations with high performance disks are strongly recommended.

^Footnote 2This may be need to be increased if Enriched data exchange is enabled.

1.5.3 Collector Requirements

The requirements for Collector systems are shown in Table 1–3:

Table 1-3 Collector System Requirements

Element	Requirement
CPU	64-bit Intel or AMD dual-core processor or equivalent.
Memory	8 GB.
Disk space	Minimum 200 GB HDD free space.
Network interfaces	When using a network-tap^Foot 1 device, a minimum of three network interfaces are required: Two interfaces for network traffic capturing^Foot 2. One interface for communication with the Reporter system. When using a network-copy port, a minimum of two network interfaces are required: One interface for network traffic capturing. One interface for communication with the Reporter system.

^Footnote 1Capturing data with a network-tap device prevents the use of a cascaded taps configuration.

^Footnote 2For up and down stream traffic. Note that the use of taps that integrate up and down stream traffic on one line is not recommended.

Important:

Please note that an Intel (or compatible) 64-bit platform is a strict requirement for both the hardware and the operating system in all deployment scenarios.

1.6 Software Requirements

The following GNU/Linux distributions are supported:

Oracle Enterprise Linux 5.x
RedHat Enterprise Linux 5.x

Encrypting Sensitive Data

If sensitive data needs to be encrypted using the ecryptfs utility, you will require Oracle Enterprise Linux 5.2. For more information, see Section 3.3.7, "Securing Sensitive Data".

1.7 Network Requirements

All server system clocks should be synchronized via NTP using UDP port 123.
Support DNS information requests over TCP and UDP port 53.
Support reports and e-mail alerts using TCP port 25.
Support SNMP traps on request from an SNMP Manager using UDP port 161/162.
The RUEI user interface is accessible over HTTPS port 443.
Each remote Collector system should be accessible by the Reporter system over port 22. It is recommended all other ports be blocked.

1.8 Client Requirements

The workstations that will access the RUEI user interface must have one of the following browsers installed:

Mozilla Firefox 2.0.
Internet Explorer 6 SP2.
Internet Explorer 7.

Note that Javascript must be enabled. No other plug-ins are required.

In addition, the workstation should have a screen resolution of 1024 * 768 (or higher).

Important:

Ensure that any pop-up blocker within the browser has been disabled.

AJAX Support

RUEI uses AJAX to enhance its user interaction. Internet Explorer relies on the MSXML control to facilitate AJAX. The AJAX dependencies can trigger a security warning when using strict security settings.

Internet Explorer 6 does not properly support transparent images in the PNG format. RUEI uses a well know fix (AlphaImageLoader) for this problem which relies on DirectX. If you are experiencing browser crashes with IE6, you may need to update your version of DirectX. The PNG fix can trigger a security warning when using strict security settings.

Footnote Legend

Footnote 1: Copy ports are also known as Switched Port Analyzer (SPAN) ports which is a feature of Cisco switches.
Footnote 2: Test Access Port (TAP) devices are provided by specialist vendors, such as NetOptics Inc.