Skip to content

SONATA Profiler: Passive profiling

Jump to bottom
Manuel Peuster edited this page Aug 31, 2017 · 1 revision

Son-profile: passive mode

This section describes the passive mode of the son-profile tool. This mode dynamically updates a service which is pre-deployed in the emulator. Resource allocation can be dynamically adjusted. Functional tests can be generated and the set of monitored metrics can be specified. During the tests, the monitored metrics will be statistically analyzed and a summary of the measured results will be generated, giving an indication of the VNF's performance and used resources.

PED file structure

Profiling experiment descriptors (PED) are YAML-based description files that define how a given network service should be automatically profiled. The main parts of the ped file are described below. At the end of this section is an example ped file.

  • service_experiments: In the passive mode, only service experiments are executed.

  • time_limit: each test run will last this period of seconds. During this period the specific test traffic is generated and metrics are gathered. Statistics such as average and confidence interval are calculated over this interval for each metric.

  • measurement_points: Each item in reflects a VNF in the service for which several configurations need to executed during each test run.

    • name: Name of the VNF in the emulator for which the configuration will be adapted.
    • configuration: List of general configuration commands that are executed once, at the beginning of the profiling.
    • cmd: Configuration command that is executed at the start of each test run.
    • cmd_order: VNF order for which the cmd needs to be executed.

  • resource_limitations: For each of the VNFs in the service, resource limitations can be specified.

  • input_metrics: MSD file that describes the metrics to be monitored for the 'input' traffic of the service. These metrics reflect the generated traffic or resource constraints that are given as input to the service during the test runs. These metrics can be monitored during the test using Grafana. The MSD file is explained here.

  • output_metrics: MSD file that describes metrics to be monitored during the test runs. These metrics reflect the effects or load induced by the generated traffic. These metrics can be monitored during the test using Grafana.

  • profile_calculations: For each of the items in this field, a plot is made at the end of the profiling run. Each plot needs a specification of which metrics to put on the X/Y axis.

Passive mode options

  • --mode passive: required to indicated passive mode.
  • -p ped_file.yml: required, path to the ped file with the profile configuration.
  • --no_display: optional, if specified no metrics are dynamically displayed during the test runs. (no use of the ncurses library to adapt the terminal window).
  • --graph_only: optional, if specified no test runs are generated, only a graph is generated from an existing result file.
  • --results_file -r: optional, path where the results are stored (default: test_results.yml in working directory).

Examples

Start default passive mode with specified ped file:

son-profile -p ped_ctrl.yml --mode passive

Start default passive mode with specified ped file and path to store the results:

son-profile -p ped_ctrl.yml --mode passive -r profile_ctrl.yml

Start default passive mode with specified ped file but only draw the result graph from a specified results file:

son-profile -p ped_ctrl.yml --mode passive --graph-only -r profile_ctrl_demo.yml

Example ped file

---
#
# This is an example for a profiling experiment descriptor (PED).
# It defines profiling experiments for the sonata-fw-vtc-service-emu example service.
#
descriptor_version: 0.1
vendor: "eu.sonata-nfv"
name: "ovs-profile-experiment"
version: "0.1"
author: "name,email"
description: "This is an example profiling experiment descriptor (PED)."

# path to the package of the service we want to profile
service_package: "./sonata-ovs-user-service.son"

#
# For son-profile passive mode only Service level experiments are taken into account
#
service_experiments:
  - name: "service_throughput"
    description: "iperf test for entire service"
    repetitions: 1
    time_limit: "11"
    # NSD to be used (SONATA-like vendor.name.version reference)
    service: "eu.sonata-nfv.sonata-fw-vtc-service.0.1"
    # additional containers for traffic generation/measurements (like SAPs)
    measurement_points:
      - name: "ns_port0"
        connection_point: "ns:serviceout"
        container: "sonata-son-emu-sap:latest"
        configuration:
          - "ethtool -K port0 tx off"
          - "arp -s 10.20.30.40 11:22:33:44:55:66"
        cmd: 'iperf -c 10.20.30.40 -t999 -u -b${1,2,3,5}M'
        cmd_order: 2
      - name: "ns_port1"
        connection_point: "ns:servicein"
        container: "sonata-son-emu-sap:latest"
        configuration:
          - "ethtool -K port1 tx off"
        cmd: 'python iperf_server.py "-s -u -i1 -fm"'
        cmd_order: 1
#
# Additional resource limitations for the VNFs in the service.
#
     resource_limitations:
       - function: "ovs1"
        cpu_bw: "${0.4 to 0.8 step 0.1}"
        cpu_cores: 1
        #mem_limit: "${256, 512}m"
        mem_limit: 256m
      - function: "ns_port0"
        cpu_bw: 0.2
        cpu_cores: 1
        mem_limit: 512m
      - function: "ns_port1"
        cpu_bw: 0.2
        cpu_cores: 1
        mem_limit: 512m
#
# Metrics that need to be monitored during the profiling tests
#
    input_metrics: "msd_input.yml"
    output_metrics: "msd_output.yml"
#
# Metrics for which a plotted analysis is made
#
    profile_calculations:
      - name: "ovs1_profile"
        input_metric: "rx_packet_rate@ovs1:port0"
        output_metric: "cpu@ovs1"
      - name: "ctrl_profile"
        input_metric: "rx_packet_rate@ctrl:ctrl-port"
        output_metric: "cpu@ctrl"

Automated profiling

We use an example service that that deploys a OvS userspace switch. The service package is located in the sonata examples repository: sonata-ovs-user-service-emu

  1. The service is first deployed on son-emu:
sudo python src/emuvim/examples/sonata_simple_topology.py

For first time execution, we need to initialize the son-access command to push to son-emu:

son-workspace --init
son-access config --platform_id emu --new --url http://127.0.0.1:5000 --default

Push and the deploy the service on the emulator:

son-access -p emu push --upload sonata-ovs-user-service.son 
son-access -p emu push --deploy latest
  1. In the service directory there are two example ped files:
  • ped1.yml: Fixed resource allocation and varying load -> characterize the optimized resource allocation for a specific load.
  • ped2.yml: Varying resource allocation and maximized load -> characterize the maximum load for a specific resource allocation.

In this yaml-based file, only the service-experiment fields are considered for automated test execution. Each experiment defines:

  • measurement_points : The commands which need to be executed in a specific VNF for configuration and to start the traffic load.
  • resource_limitations : The resource allocation per VNF in the service.

The metrics to be monitored are specified in a separate msd file which is referenced in the ped file:

  • input_metrics: "msd_input.yml"
  • output_metrics: "msd_output.yml" The specified metrics are exported by son-emu and cAdvisor and gathered in a Prometheus database. Additionally, these metrics can be monitored in a Grafana web gui at http://<son-emu-host>:3000
  1. The service must be pre-deployed on son-emu before the profiling is started. To start the profiling:
son-profile -c ped1.yml --no-generation  --no-display

The test results are exported to a .yml file: test_results.yml The following command will also print the measured metrics in real-time while the test is executing:

son-profile -c ped1.yml --no-generation
Clone this wiki locally