diff options
Diffstat (limited to 'docs/scenarios/os-odl_l3-fdio-noha')
| -rwxr-xr-x | docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png | bin | 0 -> 168854 bytes | |||
| -rwxr-xr-x | docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg | bin | 0 -> 184742 bytes | |||
| -rwxr-xr-x | docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png | bin | 0 -> 103223 bytes | |||
| -rwxr-xr-x | docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png | bin | 0 -> 295451 bytes | |||
| -rwxr-xr-x | docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst | 245 |
5 files changed, 128 insertions, 117 deletions
diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png Binary files differnew file mode 100755 index 0000000..27c8335 --- /dev/null +++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg b/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg Binary files differnew file mode 100755 index 0000000..e92851f --- /dev/null +++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png Binary files differnew file mode 100755 index 0000000..1193ea4 --- /dev/null +++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png Binary files differnew file mode 100755 index 0000000..04546aa --- /dev/null +++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png diff --git a/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst b/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst index bf32eb6..6bbf12b 100755 --- a/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst +++ b/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst @@ -40,8 +40,8 @@ NFV infrastructure are reflect different business In order to meet the desired qualities of an NFV infrastructure, the -following components were chosen for the "Openstack - OpenDaylight - - FD.io/VPP" scenario: +following components were chosen for the "Openstack - OpenDaylight - FD.io" +scenario: * FD.io Vector Packet Processor (VPP) - a highly scalable, high performance, extensible virtual forwarder * OpenDaylight Controller - an extensible controller platform which @@ -52,7 +52,7 @@ following components were chosen for the "Openstack - OpenDaylight deployment. -The "Openstack - OpenDaylight - FD.io/VPP" scenario provides the capability to +The "Openstack - OpenDaylight - FD.io" scenario provides the capability to realize a set of use-cases relevant to the deployment of NFV nodes instantiated by means of an Openstack orchestration system on FD.io/VPP enabled compute nodes. The role of the Opendaylight network controller in this integration is @@ -74,22 +74,30 @@ servers: * 1 Jumphost hosting the APEX installer - running the Undercloud * 1 Controlhost, which runs the Overcloud as well as OpenDaylight as a network controller - * 2 or more Computehosts - -.. image:: FDS-odl_l3-overview.png - -Tenant and public networking leverages FD.io/VPP. VPP binds to both, the tenant -networking interface as well as to the public networking interface on the -compute and control nodes. The OpenDaylight network controller is used to setup -and manage layer 2 and layer 3 networking for the scenario - with Group Based -Policy (GBP) being the key component. Tenant networking can either leverage -VXLAN (in which case a full mesh of VXLAN tunnels is created) or VLANs. Layer 3 -connectivity is provided by using VPP as a "distributed virtual router". - -The picture below gives an example for distributed routing using VRFs between -tenant networks. - -.. image:: FDS-L3-DVR-example.png + * 2 or more Computehosts. One of the Computehosts also serves as + layer 3 gateway for the tenant networks. + +.. image:: FDS-odl_l3-noha-overview.png + +Tenant and public networking leverages FD.io/VPP. On one of the compute nodes, +VPP binds to both, the tenant networking interface as well as to the public +networking interface. This means that VPP is used for communication within +a tenant network, between tenant networks, as well as between a tenant network +and the Internet. Note that this setup slightly differs from the usual +centralized L3 setup with qrouter on the control node. This setup was chosen +to limit the configuration changes for the introduction of FD.io/VPP. The +OpenDaylight network controller is used to setup and manage layer 2 and +layer 3 networking for the scenario - with Group Based Policy (GBP) being the +key component. Tenant networking can either leverage VXLAN (in which case a +full mesh of VXLAN tunnels is created) or VLANs. + +The picture below shows an example setup with two compute and one control +node. Note that the external network is connected via compute node 0 through +VPP. VPP provides all layer 3 services which are provided in a "vanilla" +OpenStack deployment, including SNAT and DNAT, as well as north-south +and east-west traffic filtering for security purposes ("security groups"). + +.. image:: FDS-L3-noha-sample-setup.png Features of the scenario ------------------------ @@ -100,7 +108,7 @@ Main features of the "apex-os-odl_l3-fdio-noha" scenario: * Fast and scalable tenant networking using FD.io/VPP as forwarder * Layer 2 networking using VLANs or VXLAN, managed and controlled through OpenDaylight - * Layer 3 connectivitiy for tenant networks supplied in a distributed way + * Layer 3 connectivitiy for tenant networks supplied through FD.io/VPP. Layer 3 features, including security groups as well as floating IP addresses (i.e. NAT) are implemented by the FD.io/VPP forwarder * Manual and automatic (via DHCP) addressing on tenant networks @@ -122,86 +130,39 @@ and the Layer 3 scenario "apex-os-odl_l3-fdio-noha" share the same components. Here's a more detailed list of the individual software components involved: -**Openstack Neutron ML2 ODL Plugin**: Handles Neutron data base synchronization -and interaction with the southbound Openstack controller using HTTP. - -**OpenDaylight Neutron Nothbound & Neutron MD-SAL Entry Store**: Presents a -Neutron (v2) extended HTTP API servlet for interaction with Openstack Neutron. -It validates and stores the received Neutron data in the MD-SAL data store -against the Neutron yang model driven. - -**OpenDaylight Neutron Mapper**: The Neutron Mapper listens to Neutron data -change events and is responsible for using Neutron data in creating Group Based -Policy Data objects, e.g. GBP End-Points, Flood-Domains. A GBP End Point -represents a specific NFV/VM port and its identity as derived from a Neutron -Port. The mapped data is stored using the GBP End Point yang model and an -association between the GBP End-Point and its Neutron object is maintained in -the Neutron-GBP map. - -**OpenDaylight Group Based Policy (GBP) Entities store**: Stores for the GBP -data artifacts against the GBP YANG schemas. - -**Neutron Group Based Policy Map store**: Stores the bi-lateral relation -between an End-Point and its corresponding Neutron object. Neutron-GBP map; -keyed by Neutron object type, port, and Neutron UUID, gives the GBP End-Point, -Flood domain respectively. GBP-Neutron map keyed by GBP object type, end-point. - -**Neutron VPP Renderer Mapper**: The Neutron VPP Renderer Mapper listens to -Neutron Store data change events, as well as being able to access directly the -store, and is responsible for converting Neutron data specifically required to -render a VPP node configuration with a given End Point, e.g. the virtual host -interface name assigned to a vhostuser socket.. The mapped data is stored in -the VPP info data store. - -**VPP Info Store**: Stores VPP specific information regarding End-Points, Flood -domains with VLAN, etc. - -**GBP Renderer Manager**: The GBP Renderer Manager is the central point for -dispatching of data to specific device renderers. It uses the information -derived from the GBP end-point and its topology entries to dispatch the task of -configuration to a specific device renderer by writing a renderer policy -configuration into the registered renderer's policy store. The renderer manager -also monitors, by being a data change listener on the VPP Renderer Policy -States, for any errors in the application of a rendered configuration. - -**Renderer Policy Config Store**: The store's schema serves as the API between -the Renderer Manager and specific Renderers like the VPP Renderer. The store -uses a a YANG modeled schema to represent all end-point and associated GBP -policy data. - -**Topology Entries Store**: The yang model based MD-SAL topology store serves -two fundamental roles: 1. It maintains a topological representation of the GBP -End Points, in the context of customer networks. 2. It maintains an association -of each (VPP) compute node's physical interfaces to their neutron provider -network (e.g. The association between an ethernet interface and a Neutron -provider network). - -**VPP Renderer**: The VPP Renderer registers an instance for VPP nodes with the -Renderer Manager by means of inserting operational data into the Renderer -Policy config store. It acts as a listener on the Renderer Policy consumes via -the GBP Policy API data + the specific VPP End Point data, to drive the -configuration of VPP devices using NETCONF Services. -More specifically, the renderer generates: - - * vhost user port configuration that corresponds to the VM port configuration - * VPP bridge instances corresponding to the GBP flood domain - * port or traffic filtering configuration, in accordance with the GBP policy. - -The VPP Renderer also interacts with the Virtual Bridge Domain Service, by -means of the VBD store, in order to establish connectivity between VPP nodes in -a bridge domain. For this it uses the VPP device name, and the flood domain -data derived from the VPP Info and End-Point data respectively. For the -executed configuration operations it updates state in the Renderer policy state -store. - -**Virtual Bridge Domain (VBD) Store and Manager**: The virtual bridge domain -manager is responsible for configuring the VxLAN overlay tunnel infrastructure -to arrive at a desired bridged topology between multiple (VPP) compute nodes. -VDB configures VXLAN tunnels always into a full-mesh with split-horizon group forwarding applied on any domain facing tunnel interface (i.e. forwarding behavior will be that used for VPLS). - -**NETCONF Mount Point Service & Connector**: Collectively referred to as -Netconf Services, provide the NETCONF interface for accessing VPP configuration -and operational data stores that are represented as NETCONF mounts. +**Openstack Neutron ML2 OpenDaylight Plugin**: Handles Neutron data base +synchronization and interaction with the southbound controller using a REST +interface. + +**ODL GBP Neutron Mapper**: Maps neutron elements like networks, subnets, +security groups, etc. to GBP entities: Creates policy and configuration for +tenants (endpoints, resolved policies, forwarding rules). + +**ODL GBP Neutron VPP Mapper**: Maps Neutron ports to VPP endpoints in GBP. + +**ODL GBP Location Manager**: Provides real location for endpoints (i.e. Which +physical node an endpoint is connected to). + +**GBP Renderer Manager**: Creates configuration for Renderers (like e.g. +VPP-Renderer or OVS-Renderer). The GBP Renderer Manager is the central point +for dispatching of data to specific device renderers. It uses the information +derived from the GBP end-point and its topology entries to dispatch the task +of configuration to a specific device renderer by writing a renderer policy +configuration into the registered renderer's policy store. The renderer +manager also monitors, by being a data change listener on the VPP Renderer +Policy States, for any errors in the application of a rendered configuration. + +**GBP VPP Renderer Interface Manager**: Listens to VPP endpoints in the +Config DataStore and configures associated interfaces on VPP via HoneyComb. + +**GBP VPP Renderer Renderer Policy Manager**: Manages the creation of +bridge domains using VBD and assigns interfaces to bridge domains. + +**Virtual Bridge Domain Manager (VBD)**: Creates bridge domains (i.e. in case +of VXLAN creates full mesh of VXLAN tunnels, configures split horizon on +tunnel endpoints etc.). VDB configures VXLAN tunnels always into a full-mesh +with split-horizon group forwarding applied on any domain facing tunnel +interface (i.e. forwarding behavior will be that used for VPLS). **Virtual Packet Processor (VPP) and Honeycomb server**: The VPP is the accelerated data plane forwarding engine relying on vhost user interfaces @@ -209,20 +170,44 @@ towards Virtual Machines created by the Nova Agent. The Honeycomb NETCONF configuration server is responsible for driving the configuration of the VPP, and collecting the operational data. -**Rendered Policy State Store**: Stores data regarding the execution of -operations performed by a given renderer. - **Nova Agent**: The Nova Agent, a sub-component of the overall Openstack architecture, is responsible for interacting with the compute node's host Libvirt API to drive the life-cycle of Virtual Machines. It, along with the compute node software, are assumed to be capable of supporting vhost user interfaces. -The picture below show a basic end to end call flow for creating a Neutron -vhostuser port on VPP using a GBP renderer. It showcases how the different -component described above interact. - -.. image:: FDS-basic-callflow.jpg +The picture below shows the key components. + +.. image:: FDS-basic-components.jpg + +To provide a better understanding how the above mentioned components interact +with each other, the following diagram shows how the example of creating a +vhost-user port on VPP through Openstack Neutron: + +To create or update a port, Neutron will send a request to ODL Neutron +Northbound which contains the UUID, along with the host-id as "vpp" and +vif-type as "vhost-user". The GBP Neutron mapper turns the "Neutron speak" of +"ports" into the generic connectivity model that GroupBasedPolicy uses. +Neutron "ports" become generic "GBP Endpoints" which can be consumed by the +GBP Renderer Manager. The GBP Renderer Manager resolves the policy for the +endpoint, i.e. it determines which communication relationships apply to the +specific endpoint, and hands the resolution to a device specific renderer, +which is the VPP renderer in the given case here. VPP renderer turns the +generic policy into VPP specific configuration. Note that in case the policy +would need to be applied to a different device, e.g. an OpenVSwitch (OVS), +then an "OVS Renderer" would be used. VPP Renderer and the topology manager +("Virtual Bridge Domain" manager - i.e. VBD) cooperate to create the actual +network configuration. VPP Renderer configures the interfaces to the virtual +machines (VM), i.e. the vhost-user interface in the given case here and +attaches them to a bridge domain on VPP. VBD handles the setup of connectivity +between bridge domains on individual VPPs, i.e. it maintains the VXLAN tunnels +in the given case here. Both VPP Renderer as well as VBD communicate with the +device through Netconf/YANG. All compute and control nodes run an instance of +VPP and the VPP-configuration agent "Honeycomb". Honeycomb serves as a +Netconf/YANG server, receives the configuration commands from VBD and VPP +Renderer and drives VPP configuration using VPP's local Java APIs. + +.. image:: FDS-simple-callflow.png Scenario Configuration ====================== @@ -232,25 +217,51 @@ settings in the APEX configuration files. Those are typically found in /etc/opnfv-apex. File "deploy_settings.yaml": Choose Opendaylight as controller with version -"boron" and enable vpp as forwarder:: - - global_params: - ha_enabled: false +"carbon" and enable vpp as forwarder. "odl_routing_node" chooses the node +which is used as the layer 3 gateway for the tenant networks. +"odl_routing_node" is an optional parameter. If omitted, the VPP on the first +compute node will serve as layer 3 gateway:: deploy_options: sdn_controller: opendaylight sdn_l3: true - odl_version: boron - tacker: false - congress: false + odl_version: carbon + odl_routing_node: overcloud-novacompute-0 + tacker: true + congress: true sfc: false vpn: false vpp: true + dataplane: fdio + performance: + Controller: + kernel: + hugepages: 1024 + hugepagesz: 2M + intel_iommu: 'on' + iommu: pt + isolcpus: 1,2 + vpp: + main-core: 1 + corelist-workers: 2 + uio-driver: uio_pci_generic + Compute: + kernel: + hugepagesz: 2M + hugepages: 2048 + intel_iommu: 'on' + iommu: pt + isolcpus: 1,2 + vpp: + main-core: 1 + corelist-workers: 2 + uio-driver: uio_pci_generic Limitations, Issues and Workarounds =================================== -There are no known issues. +For specific information on limitations and issues, please refer to the APEX +installer release notes. References ========== @@ -260,4 +271,4 @@ References * Fast Data (FD.io): https://fd.io/ * FD.io Vector Packet Processor (VPP): https://wiki.fd.io/view/VPP * OpenDaylight Controller: https://www.opendaylight.org/ - * OPNFV Colorado release - more information: http://www.opnfv.org/colorado + * OPNFV Danube release - more information: http://www.opnfv.org/danube |
