What is perfSONAR?

perfSONAR is a collection of open source software for performing and sharing end-to-end network measurements. It consists of multiple tools brought together in a manner best illustrated in the diagram below:

_images/intro_about-arch.png

Your deployment may install some or all of the components depending on your goals. See perfSONAR Installation Options for a discussion on how to choose a deployment strategy that best suits your needs.

The sections that follow provide a brief in overview of the components at each layer and provide links to more detail where applicable.

Tools

perfSONAR includes numerous utilities responsible for carrying out the actual network measurements and form the foundational layer of perfSONAR. In general, you will not invoke these tools directly but instead use the pscheduler command from the scheduling layer to execute them. The default tools that come with perfSONAR include:

  • owamp - A set of tools primarily used for measuring packet loss and one-way delay. It includes the command owping for single short-lived tests and the powstream command for long-running background tests.
  • twamp - A tool primarily used for measuring packet loss and two-way delay. It has increased accuracy over tools like ping without the same clock synchronization requirements as OWAMP. The client tool is named twping and can be used to run against TWAMP servers. You can use the provided twampd server or many routers also come with vendor implementation of TWAMP servers that can be tested against.
  • iperf3 - A rewrite of the classic iperf tool used to measure network throughput and associated metrics.
  • iperf2 - Also known as just iperf, a common tool used to measure network throughput that has been around for many years.
  • nuttcp - Another throughput tool with some useful options not found in other tools.
  • traceroute - The classic packet trace tool used in identifying network paths
  • tracepath - Another path trace tool that also measures path MTU
  • paris-traceroute - A packet trace tool that attempts to identify paths in the presence of load balancers
  • ping - The classic utility for determining reachability, round-trip time (RTT) and basic packet loss.

Scheduling

The scheduling layer consists of a single tool named pScheduler and is responsible for:

  1. Finding time-slots to run the tools while avoiding scheduling conflicts that would negatively impact results
  2. Executing the tools and gathering results
  3. Sending to the results to the archiving layer (if needed)

More information on using the pScheduler can be found in the section Running Measurements with pScheduler.

Archiving

The archiving layer currently consists a single component named esmond that stores measurement information as time-series data. It is often referred to as the measurement archive (MA) and the term is used interchangeably with esmond. It can be installed on each measurement host if they meet hardware requirements or a single central instance may store results from multiple measurement hosts. For more information on esmond see the esmond documentation. For information on running a central measurement archive see Deploying a Central Measurement Archive.

Configuration

The configuration layer is where desired measurements are defined along with instructions on where to store them. The primary component at this layer is called pSConfig. pSConfig is a template framework for describing and configuring a topology of tasks. If you manage more than one perfSONAR host (or participate in a distributed community of perfSONAR measurement hosts), the following configuration tasks can quickly become unwieldy:

  1. Scheduling the tasks you want to run at each location.
  2. Maintaining visualization components to display results of the measurements from multiple hosts

pSConfig assists with these challenges by providing agents to automate each of the configuration tasks listed above. This includes:

  1. pSconfig pScheduler Agent - The agent responsible for reading a template and configuring the tasks defined in pScheduler. See Running the pSConfig pScheduler Agent for more details on this agent.
  2. pSConfig MaDDash Agent - The agent responsible for reading a template and configuring MaDDash to display the results of defined tasks in a dashboard. See Running the pSConfig MaDDash Agent for more details on this agent.

For complete information on pSConfig start with What is pSConfig? for more details on pSConfig basic concepts/terminology.

Visualization

perfSONAR also includes components for visualizing the data. These components provide a window into the data and are the primary way most operators analyze and identify network issues. The primary tools provided by the main perfSONAR project are:

  • Graphs - The perfSONAR graphs package provides a set of graphs that display the various measurements over time and provide useful information about the hosts involved. See Test Results Graphs for more detail.
  • MaDDash - This component queries the archiving layer periodically for measurements and displays a dashboard indicating the performance of each relative to a set of defined thresholds. It can also send alerts based on patterns in the dashboard. See the MaDDash documentation for more details.

In addition to displaying results, there are also graphical interfaces available for configuring perfSONAR components:

  • Toolkit GUI - This ships with every perfSONAR Toolkit and allows defining tasks for the local pSConfig pScheduler agent. See Configuring Regular Tests for more details.
  • pSConfig Web Admin - This is a web-based application for defining remote templates that can be read by the pSConfig Agents. See pSConfig Web Admin for more details.

Discovery

Each perfSONAR node can run a component called the Lookup Service (LS) Registration Daemon that registers its existence in a public and/or private lookup service. The registration daemon gathers information about each perfSONAR layer as well as the host on which it runs. This information is then used in multiple places to help debug problems and find hosts with which to test when building new configurations.

In general, no configuration is needed of the registration component but for a guide of the options available see Lookup Service Registration Daemon Configuration File. For a guide on automatically building test configurations based on registered lookup service content see pSConfig Auto-Configuration.