-
Notifications
You must be signed in to change notification settings - Fork 3
Installation
Here are some tips for how to relate the software Architecture to nuts and bolts like files to install and init scripts to write.
There is only one file to install: snabb. To create this file you can checkout the snabbswitch repository and run make at the top level to produce src/snabb. You can install this in a standard location such as /usr/bin/snabb.
snabb is a stand-alone executable that contains all of the required functions as sub-commands (in the style of busybox).
The relevant usages are:
-
snabb snabbfv traffic ...on the compute node does the traffic processing. -
snabb snabbnfv neutron-sync-master ...on the database node(s) makes the Neutron configuration available to compute nodes. -
snabb snabbnfv neutron-sync-agent ...on the compute nodes to poll the master for configuration updates. -
snabb snabbnfv neutron2snabb ...to translate the Neutron database into configuration files for the local traffic processes. This command is called automatically fromneutron_sync_agent.
The traffic command has no external software dependencies. Other commands expect certain programs to be in the PATH to call: snabb, git, mysqldump, diff, and standard shellutils.
These are the services that should run in addition to OpenStack itself:
-
neutron_sync_master: One instance per database server. -
neutron_sync_agent: One instance per compute node. -
traffic: One instance per 10G traffic port on each compute node.
The traffic process should run on a reserved CPU core (see Compute node requirements). The core is best assigned with taskset -c <core> snabb snabbnfv traffic .... Note: The command numactl seems to be incompatible with the Linux isolcpus feature and for this reason it is not recommended.
The command line arguments for each process can be determined by reading the usage and considering whether the default is suitable.
The processes print log messages to stdout and these should be redirected to a suitable location such as syslog.
For the traffic process we recommend you consider using arguments similar to these:
-
--load-report-interval 10for one-line summaries of traffic load every ten seconds. -
--link-report-interval 60for a summary of internal traffic within the process every one minute. -
--debug-report-interval 600for a dump of the NIC internal counter and status registers every 10 minutes.
The traffic process is designed to be safe to restart. If it detects an error it will terminate with a message and expect to be restarted. Once restarted it will continue serving traffic for the virtual machines. (Stateful packet filtering connection tables are reset during restarts, however.)
We recommend you always restart the traffic process when it terminates, after some reasonable delay (e.g. between one and ten seconds).