Distributed Architecture

How does the distributed infrastructure work?

Appliances hosting only the sniffer component of PVX are called “captures” (called “pollers” in older versions of PVX). The appliance hosting the components in charge of collecting, merging and integrating the data from the capture probes into a single database is called a “datastore”. The datastore appliance may also host one sniffer component.

The captures listen and analyze the network traffic. The datastore receives data from the captures, integrates them into the database, and then provides an access to the data through the Web UI.

The Nodes Management page in the Configuration menu displays some status information about captures.

Where is data being merged / segregated?

The data is merged (i.e., the data is integrated in the reports with no consideration for the capture which has captured it) in:

• Business Critical Application Dashboard
• Application dashboards
• Graphs (performance, bandwidth, matrix)
• Comparison tables (Client / Server, Network performance, Application performance)

Please note that in these reports, you can enter a filter to view the data captured by one capture only. The data is segregated (i.e., the data is kept separated depending on the capture which captured the data) in all other tables. Please note that in reports you will get two lines for a single conversation viewed by two captures.

How to configure a capture probe

The preferred way to configure a capture probe is through the Nodes Management page in the Configuration menu.

To add a new capture, simply use the Add a Capture button to be guided through the necessary steps.

Enter the IP or DNS of the capture to be registered and click Next.

To ensure you are not a victim of any attack or impersonation, the datastore needs a PIN code to authenticate itself and will present you the SSH key fingerprint of the capture you’re trying to add.

To generate a PIN code, use the Pulsar shell on the capture, with the register pin create command.

The PIN code creation on a capture will also show you that capture’s key fingerprint needed to confirm it on the datastore.

You should first check that the key fingerprint shown by the datastore is the capture’s fingerprint. Once verified, enter the PIN code and click the Register button.

To edit the capture’s configuration you may click on its name or select it and click the Configure button on the top-left of the page. Note that you can edit multiple captures simultaneously.

Any modification performed here will be applied to the capture after a short time.

What happens if a capture probe does not respond?

A capture that is missing won’t impact the data integration for the other captures. The data of the missing capture will be temporarily stored on the capture itself for a limited amout of time (which is configurable via Pulsar by using the csv retention command). When the capture becomes reachable again, the datastore will integrate its stored data.

Limits

The distributed architecture provided by version 2.5 has some intrinsic limits:

• There is no feature for deduplication between captures (i.e., a network flow captured by two captures will be counted twice in reports that merge data from several captures). [1] However, you can filter the data for each capture.
• If there is some load balancing at the packet level (and not at the session level) and two captures view two different parts of the traffic, the datastore will not be able to rebuild these flows and no performance metric will be available in this case. [2]
• The positioning of each capture with regards to client and server will have some impact on certain metrics (SRT, RTT Server, RTT Client, RR Server, RR Client, etc.).
• The maximum number of sessions handled by the datastore remains unchanged (approximately 100k concurring sessions).

Prerequisites

• All captures have to be synchronized to a single NTP.
• All captures and datastore require an administration port connected to the network and a fixed IP address.
• Connectivity between captures and datastore on port TCP/22 is required.
• Some network capacity is required to transfer the data from the captures to the datastore (current evaluation is 0.2% of the analyzed bandwidth).

Adequate / Non-Adequate Implementations

[1] This is a rare case and is not handled by the non-distributed implementation of SkyLIGHT PVX nor by most competitors. The bypass option would be to use TAPs to reaggregate both flows before it reaches the interface of the capture.

[2] This is already the case in a non-distributed implementation. The only new element is the fact that data will be more readable if all captures have the same capture points.