This is the starting page for the deployment and usage documentation of SONATA Project. The page will guide you through the SONATA architecture and present the main building blocks of the SONATA Service Platform. Following it provides installations details and links to the SONATA Github repositories. Finally it provides some usage guidelines for the SONATA service platform.
Using the SONATA System is quite straight forward, you only need to follow the main steps shown in the general workflow figure bellow and explained in detail the following sections.
The recommended workflow when developing a SONATA network service consists on using the CLI tools to create a workspace, create a project to hold the descriptors of the service, validate the components and finally, create a bundled service package. The required steps are as follows:
son-workspace --project project_dir
After this step, a sample Network Service Descriptor (NSD) and several Virtual Network Function Descriptors (VNFDs) are available at
Use a text editor of choice to edit the descriptors.
son-validate --project project_dir
son-package --project project_dir -n service_package
After this step, if everything is correct, a package file named
service_package.son will be created.
son-access push --upload service_package.son
These are the most basic steps to develop a network service, however additional features may be used and configuration procedures may take place, when required. For instance, to compose a NSDs and VNFDs, the son-editor GUI may be used. Likewise, the son-validator GUI can also be used to trigger validations and visualize the resulting errors, the service network topology, the forwarding graphs, etc. Regarding configuration procedures, before step 6 takes place (onboard a network service to the service platform) the service platform URL and user credentials must be configured in the workspace. To learn more about the additional features and configuration requirements please consult the wiki [documentation](https://github.com/sonata-nfv/son-cli/wiki) of son-cli repository.
To develop a new FSM or SSM the following steps needs to be taken:
First thing to configure is the the name of the FSM/SSM. In order to provide meaningful names for FSMs/SSMs and also avoid FSMs/SSMs name collision in Service Platform, A naming pattern is defined in SM template that contains the following fields:
For SSMs, the name includes:
Fro FSMs, the name includes:
In the following you can find a short description of the mentioned above fields:
|Fields||Description||Required for||Provided by|
||the FSM/SSM type which could be either fsm or ssm.||FSMs/SSMs||Developer|
||the name of the service that the FSM/SSM belongs to||FSMs/SSMs||Developer|
||the name of the VNF that the fsm belongs to||FSMs||Developer|
||the actual fsm/ssm name (e.g., placement, scaling)||FSMs/SSMs||Developer|
||an id number to differentiate FSMs/SSMs developed for the same purpose)||FSMs/SSMs||Developer|
||version of the FSM/SSM||FSMs/SSMs||Developer|
||the FSM/SSM description||FSMs/SSMs||Developer|
||the FSM/SSM unique identifier||FSMs/SSMs||SMR|
||the unique identifier of service/VNF that the FSM/SSM belongs to||FSMs/SSMs||FLM/SLM|
||needs the be populated by
Once you are done with filling these fields you can start developing the actual function of your SSM/FSM by overwriting the on_registration_ok function of the template.
Put your SSM/FSM in a docker container and push it to your own docker hub. Here you can create your own docker hub account to push your FSMs/SSMs there.
Put the SSM’s id and URL in the NSD and the FSM’s id and URL in the VNFD
function_specific_managers: - id: "sonfsmservice1firewallplacement1" description: "placement FSM for firrewall" image: "hadik3r/sonfsmservice1firewallplacement1" - id: "sonfsmservice1firewallscaling1" description: "scaling FSM for firrewall" image: "hadik3r/sonfsmservice1firewallscaling1"
This step can be useful in order not to wait until Infrastructure abstraction downloads the image from the external link. You can upload it to glance before instantiating the NS. The instantiation will be really fast.
You can upload the image following this link Openstack Manage images
Notice that the VNF image name has to be composed by:
- vnf_id: "vtc_vnf" vnf_vendor: "eu.sonata-nfv" vnf_name: "vtc-vnf" vnf_version: "0.1"
And in the vnfd in the virtual_deployment_units section:
- id: "1"
The final name in glance will be:
The VNF is accessible here: VTC VNF
To deploy and test a network service on the emulation platform you can use the son-cli tools just like you would do when pushing a service to the service platform. You can find an example service package and a detailed description of the workflow online. The main steps are as follows:
svn export https://github.com/sonata-nfv/son-tutorials/trunk/upb-containernet-emulator-summerschool-demo demo
sudo python ~/demo/topologies/son-emu_example3.py
son-package --project demo/sonata-demo-service -n sonata-demo-service
son-access push --upload sonata-demo-service.son
son-access push --deploy
son-emu-cli compute list
The output will show you the running VNFs of the service and the emulated datacenters:
|Datacenter||Container||Image||Interface list||Datacenter interfaces|
To monitor a service running under
son-monitor requires a Monitor Service Descriptor (
msd). It describes which metrics to gather on the specified VNFs. A detailed explanation on building a
msd can be found here. For this quick guide, the following
msd can be used:
service_name: "sonata-demo-service" version: "0.1" author: "SONATA" description: "Monitor descriptor example for the quick use guide" dashboard: "son-demo-service" vnf_metrics: - metric_type: "cpu" description: "cpu load (%)" vnf_ids: - vnf: "snort_vnf" nsd_links: - metric_type: "packet_count" description: "packet_count of links" link_ids: - description: "example tx traffic" link_id: "link-12" source: "client:client-eth0" destination: "snort_vnf:input" direction: "tx" - description: "example rx traffic" link_id: "link-32" source: "snort_vnf:output" destination: "server:server-eth0" direction: "rx"
son-monitoris started with:
son-monitor init start
son-monitor msd -f sonata_demo_service.yml start
son-monitor msd -f sonata_demo_service.yml stop
son-monitor init stop
son-monitor wiki pages contain more information on how to use this tool.
The metrics generated by a running service can be analysed using
son-analyze. This tool will bring a service’s metrics inside an environment where the developer can further analyse them.
son-analyzeneed to be bootstrapped:
Further information can be found in the
son-analyze wiki pages.
Package on-boarding in SONATA consists of a sequence of steps, performed before the package is stored in the platform’s Catalogues. These steps guarantee that only valid packages are made available to the platform owner’s customers. That sequence of steps are the following:
With this last step concluded successfully, the service remains ready to be instantiated by any customer of the SP owner (see the following sub-section).
(In order to proceed with the network service instantiation, it's necessary the service catalogue contains at least one service)
The easiest way to deploy monitoring probe is as Docker container but it can be installed also as a service.
git clone https://github.com/sonata-nfv/son-monitor-probe.git cd son-monitor-probe sudo docker build -f vm_mon/Dockerfile -t son-vm-probe .
Alternately, you can pull the latest image from Sonata’s repository in Docker Hub
sudo docker pull sonatanfv/son-monitor-probe:latest
sudo docker run -d --name son-vm-probe -e NODE_NAME=VNF_1 -e PROM_SRV=http://<service_platform_ip>:9091/metrics --net="host" --privileged=true -v /proc:/myhost/proc -v /:/rootfs:ro son-vm-probe
More details about installation alternatives can be found in GitHub wiki.
GUI provides monitoring data related to the components comprising the Sonata service platform and also the deployed VNFs. This information is organized in two views (named ‘Service platform’ and ‘VNFs’ ) under the Monitoring menu. Developers can access to monitoring data that are related with the VNFs of their NS using GUI.