OSM Release FOUR: Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
mNo edit summary
No edit summary
Line 19: Line 19:
* OSM talks to the VNFs deployed in a VIM to run day-0, day-1 and day-2 configuration primitives.
* OSM talks to the VNFs deployed in a VIM to run day-0, day-1 and day-2 configuration primitives.


[[File:Osmtopology.png|400px|OSM Release 4]]
[[File:Osmtopology..png|400px|OSM Release 4]]


In order for OSM to work, it is assumed that:
In order for OSM to work, it is assumed that:

Revision as of 20:57, 15 May 2018

[work in progress!!!]

3hackdate.png

Open Source MANO (OSM) is the open source community that aims to deliver a production-quality MANO stack for NFV, capable of consuming openly published information models, available to everyone, suitable for all VNFs, operationally significant and VIM-independent. OSM is aligned to NFV ISG information models while providing first-hand feedback based on its implementation experience.

Its Release Four has focused on exposing a model-Driven Nothbound interface, improvements to NS monitoring, improved modeling and networking, enhanced user experience and a cloud-native build.

Assumptions about interaction with VIMs and VNFs

The following figure illustrates OSM interaction with VIM and VNFs:

  • OSM talks to the VIM for the deployment of VNFs and VLs connecting them
  • OSM talks to the VNFs deployed in a VIM to run day-0, day-1 and day-2 configuration primitives.

OSM Release 4

In order for OSM to work, it is assumed that:

  • Each VIM has an API endpoint reachable from OSM
  • Each VIM has a so called management network which provides IP address to VNFs
  • That management network is reachable from OSM

Install OSM Release FOUR

This release introduces a new lightweight build, which is a cloud-native, dockerized OSM installation featuring a new kafka bus for asynchronous communications, a lighter orchestrator, performance/fault management features, a SOL005-aligned NBI, and a new GUI and OSM client leveraging the unified REST API that the NBI exposes. This build does not include the SO and UI components, which are still available in the classic build.

Install the lightweight build from source (Recommended)

All you need to run OSM Release FOUR is a single server or VM with the following requirements:

  • MINIMUM: 1 CPUs, 4 GB RAM, 20GB disk and a single interface with Internet access
  • RECOMMENDED: 2 CPUs, 8 GB RAM, 40GB disk and a single interface with Internet access
  • Ubuntu16.04 (64-bit variant required) as base image (http://releases.ubuntu.com/16.04/)

Once you have prepared the host with the previous requirements, all you need to do is:

wget https://osm-download.etsi.org/ftp/osm-4.0-four/install_osm_release.sh
chmod +x install_osm_release.sh
./install_osm_release.sh

After the installation completes, you will need to add the following environment variables to the end of your .bashrc file and then source it with source .bashrc

export OSM_HOSTNAME=127.0.0.1
export OSM_SOL005=True

Install the classic build from binaries

The classic build can still be installed, but will not bring significant new features as compared to Release THREE. To install the latest OSM classic build from source, requirements are the following:

  • 8 CPUs, 16 GB RAM, 100GB disk and a single interface with Internet access
  • Ubuntu16.04 (64-bit variant required) as base image (http://releases.ubuntu.com/16.04/), configured to run LXD containers. If you don't have LXD configured, you can follow the instructions here (LXD configuration).

Once you have prepared the host with the previous requirements, all you need to do is:

wget https://osm-download.etsi.org/ftp/osm-4.0-four/install_osm_release.sh
chmod +x install_osm_release.sh
./install_osm_release.sh --soui

Other considerations regarding LXC and connectivity apply as in Release THREE. From now on this document will focus on the new default build.

Checking your installation

After some time, you will get a fresh OSM Release FOUR installation. You can access to the UI in the following URL (user:admin, password: admin): http://1.2.3.4, replacing 1.2.3.4 with the IP address of your host.

OSM home

OSM Release FOUR installation result

As a result of the installation, ten docker containers are created in the host. You can check they are running by issuing the following commands:

docker stack ps osm |grep -i running
docker service ls

OSM Docker containers

At any time, you can quickly relaunch your deployment by using the pre-built docker images, like this:

docker stack rm osm
docker stack deploy -c /usr/share/osm-devops/installers/docker/docker-compose.yaml osm

To check the logs of any container:

docker service logs osm_lcm         # for LCM

OSM client, a python-based CLI for OSM, will be available as well in the host machine. Via the OSM client, you can manage descriptors, NS and VIM complete lifecycle and some new performance and fault-management features.

Adding VIM accounts

Before proceeding, make sure that you have a site with a VIM configured to run with OSM. Different kinds of VIMs are currently supported by OSM:

OSM can manage external SDN controllers to perform the dataplane underlay network connectivity on behalve of the VIM. See EPA and SDN assist

Adding VIMs through OSM client

OpenVIM site

  • Execute the following command, using the appropriate parameters (e.g. site name: "openvim-site", IP address: 10.10.10.10, VIM tenant: "osm")
osm vim-create --name openvim-site --auth_url http://10.10.10.10:9080/openvim --account_type openvim --description "Openvim site" --tenant osm --user dummy --password dummy

Openstack site

  • Execute the following command, using the appropriate parameters (e.g. site name: "openstack-site", IP address: 10.10.10.11, VIM tenant: "admin", user: "admin", password: "userpwd")
osm vim-create --name openstack-site --user admin --password userpwd --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack

VMware vCloud Director site

  • Execute the following command, using the appropriate parameters (e.g. site name: "vmware-site", IP address: 10.10.10.12, VIM tenant: "vmware-tenant", user: "osm", password: "osm4u", admin user: "admin", admin password: "adminpwd", organization: "orgVDC")
osm vim-create --name vmware-site --user osm --password osm4u --auth_url https://10.10.10.12 --tenant vmware-tenant  --account_type vmware          --config '{admin_username: user, admin_password: passwd, orgname: organization, nsx_manager: "http://10.10.10.12", nsx_user: user, nsx_password: userpwd,"vcenter_port": port, "vcenter_user":user, "vcenter_password":password, "vcenter_ip": 10.10.10.14}'

VMware Integrated Openstack (VIO) site

  • Execute the following command, using the appropriate parameters (e.g. site name: "openstack-site-vio4", IP address: 10.10.10.12, VIM tenant: "admin", user: "admin", password: "passwd")
osm vim-create --name VIO --user admin --password passwd --auth_url https://10.10.10.12:5000/v3 --tenant admin \

--account_type openstack \ --config '{use_floating_ip: True, insecure: true, vim_type: VIO, APIversion: v3.3, dataplane_physical_net: dvs-46, "use_internal_endpoint":true,"dataplane_net_vlan_range":["31-35","37-39"]}'

With respect to Openstack, the additional configuration for VIO is the following:

  • vim_type: Set to "VIO" to use VMware Integrated openstack as VIM
  • use_internal_endpoint: When true it allows use of private API endpoints
  • dataplane_physical_net: The configured network_vlan_ranges at neutron for the SRIOV (binding direct) and passthrough (binding direct-physical) networks, e.g. 'physnet_sriov' in the above configuration. In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch, e.g 'dvs-46' in above configuration.
  • dataplane_net_vlan_range: In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']

Amazon Web Services (AWS) site

  • Execute the following command, using the appropriate parameters (e.g. site name: "aws-site", VIM tenant: "admin", user: "XXX", password: "YYY")
osm vim-create --name aws-site --user XXX --password YYY --auth_url https://aws.amazon.com --tenant admin --account_type aws --config '{region_name: eu-central-1, flavor_info: {t2.nano: {cpus: 1, disk: 100, ram: 512}, t2.micro: {cpus: 1, disk: 100, ram: 1024}, t2.small: {cpus: 1, disk: 100, ram: 2048}, m1.small: {cpus: 1, disk: 160, ram: 1741}}}'

Adding VIMs through GUI

Just access the VIM Accounts tab, click the New VIM button and fill the parameters accordingly.

Osmvim.png

Deploying your first Network Service

In this example we will deploy the following Network Service, consisting of two simple VNFs based on CirrOS connected by a simple VLD.

NS with 2 CirrOS VNF

Before going on, download the required VNF and NS packages from this URL: https://osm-download.etsi.org/ftp/osm-3.0-three/examples/cirros_2vnf_ns/

Uploading VNF image to the VIM

Get the cirros 0.3.4 image from the following link: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img

Then, onboard the image into the VIM. The instruction differs from one VIM to another:

  • In Openstack:
openstack image create --file="./cirros-0.3.4-x86_64-disk.img" --container-format=bare --disk-format=qcow2 cirros034
  • In openvim:
#copy your image to the NFS shared folder (e.g. /mnt/openvim-nfs)
cp ./cirros-0.3.4-x86_64-disk.img /mnt/openvim-nfs/
openvim image-create --name cirros034 --path /mnt/openvim-nfs/cirros-0.3.4-x86_64-disk.img

Onboarding a VNF

  • From the UI:
    • Go to Catalog
    • Click on the import button, then VNFD
    • Drag and drop the VNF package file cirros_vnf.tar.gz in the importing area.

Onboarding a VNF

  • From OSM client:
osm upload-package cirros_vnf.tar.gz
osm vnfd-list

Onboarding a NS

  • From the UI:
    • Go to Catalog
    • Click on the import button, then NSD
    • Drag and drop the NS package file cirros_2vnf_ns.tar.gz in the importing area.
  • From OSM client:
osm upload-package cirros_2vnf_ns.tar.gz
osm nsd-list

Instantiating the NS

  • From the UI:
    • Go to Launchpad > Instantiate
    • Select the NS descriptor to be instantiated, and click on Next
    • Add a name to the NS instance, and click on Launch.

Instantiating a NS (step 1) Instantiating a NS (step 2)

  • From OSM client:
osm ns-create --nsd_name cirros_2vnf_ns --ns_name <ns-instance-name> --vim_account <data-center-name>
osm ns-list

Using OSM to view instantiated NS details

OSM client can be used to manage the NSD and VNF catalog, as well as deploying and undeploying NS instances:

osm vnfd-list             # show the vnfd catalog
osm nsd-list              # show the nsd catalog
osm ns-list               # show ns instances
osm ns-show <id|name>     # show the details of a running ns instance
osm vnf-list              # show vnf instances
osm vnf-show <id|name>    # show the details of a running vnf instance

Using old descriptors from Release TWO

Beware that old Release TWO descriptors cannot be directly used by OSM Release THREE.

You should use this conversion tool to convert them to Release THREE format and create the corresponding package.

Additional information

Your feedback is most welcome!
You can send us your comments and questions to OSM_TECH@list.etsi.org
Or join the OpenSourceMANO Slack Workplace
See hereafter some best practices to report issues on OSM