From 12a05d6f8632b24f6687ba8b820e4889e3dc359d Mon Sep 17 00:00:00 2001 From: Frank Brockners Date: Thu, 11 Aug 2016 08:10:41 -0700 Subject: Proper directory structure for scenario docs Evolving the scenario documentation to meet the directory structure required by the OPNFV tool chain Change-Id: Iab441dff604446ea06d3b928e5c5e03c6c141bfc Signed-off-by: Frank Brockners --- .../userguide/scenario-apex-os-nosdn-fdio-noha.rst | 110 --------------------- 1 file changed, 110 deletions(-) delete mode 100755 docs/userguide/scenario-apex-os-nosdn-fdio-noha.rst (limited to 'docs/userguide/scenario-apex-os-nosdn-fdio-noha.rst') diff --git a/docs/userguide/scenario-apex-os-nosdn-fdio-noha.rst b/docs/userguide/scenario-apex-os-nosdn-fdio-noha.rst deleted file mode 100755 index b863aee..0000000 --- a/docs/userguide/scenario-apex-os-nosdn-fdio-noha.rst +++ /dev/null @@ -1,110 +0,0 @@ -.. OPNFV - Open Platform for Network Function Virtualization -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Scenario: "OpenStack - FD.io" -============================= - -Scenario: apex-os-nosdn-fdio-noha - -"apex-os-nosdn-noha" is a scenario developed as part of the FastDataStacks -OPNFV project. The main components of the "apex-os-nosdn-fdio-noha" scenario -are: - - - APEX (TripleO) installer (please also see APEX installer documentation) - - Openstack (in non-HA configuration) - - FD.io/VPP virtual forwarder for tenant networking - -Scenario Overview -================== - -Basics ------- - -The "Openstack - FD.io/VPP" 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. - -A deployment of the "apex-os-nosdn-fdio-noha" scenario consists of 3 or more -servers: - - * 1 Jumphost hosting the APEX installer - running the Undercloud - * 1 Controlhost, which runs the Overcloud and Openstack services - * 1 or more Computehosts - -.. image:: FDS-nosdn-overview.png - -Tenant networking leverages FD.io/VPP. Open VSwitch (OVS) is used for all other -connectivity, in particular the connectivity to public networking / the -Internet (i.e. br-ext) is performed via OVS as in any standard OpenStack -deployment. A VPP management agent is used to setup and manage layer 2 -networking for the scenario. Tenant networking can either leverage VLANs or -plain interfaces. Layer 3 connectivity for a tenant network is provided -centrally via qrouter on the control node. As in a standard OpenStack -deployment, the Layer3 agent configures the qrouter and associated rulesets for -security (security groups) and NAT (floating IPs). Public IP network -connectivity for a tenant network is provided by interconnecting the VPP-based -bridge domain representing the tenant network to qrouter using a tap interface. -The setup is depicted below: - -Features of the scenario ------------------------- - -Main features of the "apex-os-odl_l2-fdio-noha" scenario: - - * Automated installation using the APEX installer - * Fast and scalable tenant networking using FD.io/VPP as forwarder - * Layer 2 networking using VLANs, managed and controlled - through the VPP ML2 plugin - * Layer 3 connectivitiy for tenant networks supplied centrally - on the Control node through standard OpenStack mechanisms. - All layer 3 features apply, including floating IPs (i.e. NAT) - and security groups. - -Networking in this scenario using VPP -------------------------------------- - -The apex-os-nosdn-fdio-noha scenario combines components from two key open -source projects: OpenStack and Fast Data (FD.io). In order to make Fast Data -(FD.io) networking available to this scenario, an ML2 mechanism driver and a -light-weight control plane agent for VPP forwarder has been created. For -details see also https://github.com/naveenjoy/networking-vpp/ - -Networking-vpp provides a Neutron ML2 mechanism driver to bring the advantages -of VPP to OpenStack deployments. - -It's been written to be as simple and readable as possible, which means it's -naive; the aim was not to write the most efficient mechanism driver ever from -right out of the gate, but to write something simple and understandable and see -how well it works and what needs to be changed. - -As a general rule, everything was implemented in the simplest way, for two -reasons: one is that one sees working results the quickes, and the other is -that it's much easier to replace a simple system with a more complex one than -it is to change a complex one. The current design will change, but the one -that's there at the moment is small and easy to read, even if it makes you pull -faces when you read it. - -Scenario Configuration -====================== - -To enable the "apex-os-nosdn-fdio-noha" scenario check the appropriate 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 - - deploy_options: - sdn_controller: false - sdn_l3: false - tacker: false - congress: false - sfc: false - vpn: false - vpp: true - -Notes and known issues -====================== -- cgit 1.2.3-korg