FUTEBOL UFES User Manual

Transcription

1 FUTEBOL UFES User Manual Authors Isabella de Albuquerque Ceravolo, Diego Cardoso - Universidade Federal do Espírito Santo Version 0.2 Abstract This document is a manual for the end-users of the FUTEBOL UFES testbed. It describes how to reserve the resources available at the UFES testbed, and also presents simple experiments that can be performed using those resources. Using those examples, the user will be able to build his/her own experiments.

2 This project has received funding from the European Union's Horizon 2020 for research, technological development, and demonstration under grant agreement no (FUTEBOL), as well from the Brazilian Ministry of Science, Technology and Innovation (MCTI) through RNP and CTIC. FUTEBOL Consortium Page 2 of 24

3 Document Revision History Version Date Description of change List of contributor(s) V0.1 12/12/2017 Description of how to allocate virtual machines V0.2 27/02/2018 Description of how to allocate virtual network functions FUTEBOL Consortium Page 3 of 24

4 Table of Contents 1 - Introduction 2 - Overall Description of the Testbed Map of the testbed 2.3 Functional Layers of the Testbed Setting up an Experiment 3. Experiments with Virtual Machines Virtual Machine RSpec Description Examples of a VM Experiments One Node Three Nodes 4. Experiments with Virtual Network Functions Virtual Network Functions RSpec Description Examples of a VNF Experiments Using a VNF template Using a quota of the cloud resources FUTEBOL Consortium Page 4 of 24

5 1 - Introduction The main objective of this document is to serve as a user guide for experimenters wishing to make an experiment in the FUTEBOL UFES testbed. As such, we describe the resources available, how to make a reservation of those resources and we also present simple experiments using each type of resource. We assume that the reader is familiar with jfed, that is, the reader already has an account in jfed, and already knows how to book resources using the graphic user interfaces. If you are not familiar with jfed, please read first the tutorial available at Readers wishing to understand how the FUTEBOL UFES testbed reserves resources are directed to the FUTEBOL deliverables, most notably the deliverables related to Work Package 4 - Converged Optical/Wireless Control Framework. Those can be obtained in the main FUTEBOL web site at If you feel that there is something missing from this manual, or that a certain point requires further explanation, please contact the FUTEBOL UFES team using the futebol-ufes@googlegroups.com. FUTEBOL Consortium Page 5 of 24

6 2 - Overall Description of the Testbed The UFES testbed was designed to allow the experimentation in the cloud. The testbed provides virtual machines (VM), virtual network functions (VNF) and layer 2 connectivity between them Testbed resources In order to allow experimentation in a cloud environment, the testbed was built on the OpenStack IaaS platform. The physical resources used as compute nodes (which is used to provide VMs and VNFs) include: One DELL server model PowerEdge R730 used as compute node, equipped with one Intel Xeon E cores 2.2 GHz, 128GB RAM, 1TB SATA Hard Drive, 4 ethernet 1 gigabit NIC. This server runs Ubuntu LTS linux with KVM virtualization platform. One DELL server model PowerEdge R230 used as compute node, equipped with one Intel Xeon E cores 3.7 GHz, 32GB RAM, 500GB SATA Hard Drive, 4 ethernet 1 gigabit NIC. This server runs Ubuntu LTS linux with KVM virtualization platform. In addition to the resources visible by the users, OpenStack requires more resources to make its services available: another server for OpenStack s management modules and a switch to provide connectivity (e.g., a controller node) Map of the testbed The resources are placed in the testbed as indicated in the following diagram. FUTEBOL Consortium Page 6 of 24

7 Fig 1. Connection diagram of the testbed local setup. Note: The user can not specify the physical location of the virtual resources. 2.3 Functional Layers of the Testbed Logically, the testbed is composed of three layers: The bottom layer provides the physical elements, such as servers. The next layer corresponds to the virtualized infrastructure, represented by the VMs and VNFs being managed by testbed control framework. Finally, at the top sits the definition of each experiment that uses the resources provided by the lower layer. FUTEBOL Consortium Page 7 of 24

8 Fig 2. Functional layers The virtualized testbed is composed by a software stack which includes OpenStack and takes care of the resource reservation in the FUTEBOL UFES: O2CMF. It is a open testbed control framework developed by UFES. For details, please visit the O2CMF s website: Readers wishing to understand the O2CMF specifications are directed to the FUTEBOL deliverables, most notably the deliverables related to Work Package 4 Converged Optical/Wireless Control Framework. Those can be obtained in the main FUTEBOL web site at Setting up an Experiment Users will be able to setup an experiment using jfed. After the user sends the login information, the AM will authenticate the user, tell him/her which resources will be available to them through RSpecs, and interact with the O2CMF on behalf of the user in order to instantiate the available resources. The AM uses the GENI v3 API which is written as a wrapper of the reference AM. FUTEBOL Consortium Page 8 of 24

9 3. Experiments with Virtual Machines This section describes how to allocate VMs and how to run simple experiments to check the operability of the nodes Virtual Machine RSpec Description The example below presents a RSPEC for a VM: < node client_id= " node0 " exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= " vm-m1.small " > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+img- ubuntu16-cloud " /> </ sliver_type > < interface client_id= "node0: eth0 " > < ip address= " " netmask= " " type= " ipv4 " /> </ interface > </ node > The VM is defined in a node tag. The attribute client_id allows user to choose a friendly name for his/her VM. In order the describe the VM s configuration there are some tags that should be nested within the node tag. The sliver_type tag holds the configuration items for the flavor (the compute, memory, and storage capacity) of the VM. Valid options for the attribute name are presented in Table 1. Nested in the sliver_type tag, user can insert a disk_image tag to specify the operating system for the VM. The available images are also presented in the Table 1. Name Memory (MB) Disk (GB) VCPUs Image vm-m1.nano Cirros vm-m1.tiny vm-m1.small Cirros CentOS 7 Cirros CentOS 7 Fedora 27 Ubuntu 16 vm-m1.medium Cirros FUTEBOL Consortium Page 9 of 24

10 CentOS 7 Fedora 27 Ubuntu 16 vm-m1.large Cirros CentOS 7 Fedora 27 Ubuntu 16 Table 1. Openstack Flavor VM Resources User can configure the network interfaces of the VM using the tag interface. Besides to define a name for the interface, user should insert a ip tag nested within the interface tag. The attributes in this tag are: address: Defines the IP address of the network interface; netmask: Defines the network mask for the IP address; type: Defines the version of the IP address. Currently, the testbed only supports IPv4. Besides to the VM specification, the user may describe the LAN connectivity. Every VM s network interface should be connected to a bridge (an element that offers layer 2 connectivity) through a link. Links from one VM to another one are not allowed. The example below shows a RSPEC that describes a bridge: < node client_id= " bridge0 " exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= " bridge " /> < interface client_id= "bridge0: eth0 " /> < interface client_id= "bridge0: eth1 " /> < interface client_id= "bridge0: eth2 " /> </ node > The bridge is also defined in a node tag. The attribute client_id allows user to choose a friendly name for the bridge. In order describe which VMs are connected through the bridge, there are some tags that should be nested within the node tag. The sliver_type tag is used to specify the type of the resource. In this case, there is only one valid option for the name attribute: bridge. User also have to describe which network FUTEBOL Consortium Page 10 of 24

11 interfaces the bridge have (in order connect the VMs), using the interface tag. The value of its attribute, client_id, should be a friendly name for the interface. The example below shows a RSPEC that describes a link: < link client_id= " link1 " > < component_manager name= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" /> < interface_ref client_id= " node0:eth0 " /> < interface_ref client_id= " bridge0:eth1 " /> < link_type name= "lan" /> </ link > The link is defined in a link tag. The attribute client_id allows user to choose a friendly name for the link. Nested in the link tag, user can describe what the link connects: The client_id attribute, from interface_ref tag, describes one point of the link. It should be filled respecting the format: <device client_id> : < interface client_id > Examples of a VM Experiments One Node This is the most basic scenario, where user book only one VM in the testbed without to do any other type of configuration on the resource. The first step is to open jfed and log in. Then pick a Virtual Machine resource. The experiment should look like the Fig 3. FUTEBOL Consortium Page 11 of 24

12 Fig 3. An experiment using only one VM. Right click on the VM icon and select 'configure option'. You will see the the dialog presented in the Fig 4. Select the UFES testbed and then click save. Fig 4. Dialog for resource configuration. FUTEBOL Consortium Page 12 of 24

13 If you take a look at the RSpec Editor tab, you should see the following: <? xml version= '1.0'?> < rspec xmlns= " type= "request" xmlns: emulab = " xmlns: delay = " xmlns: jfed-command = " xmlns: client = " xmlns: jfed-ssh-keys = " xmlns: jfed = " xmlns: sharedvlan = " xmlns: xsi = " xsi :schemalocation= " " > < node client_id= "node0" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "vm-m1.small" /> < location xmlns= " x= "244.0" y= "157.0" /> </ node > </ rspec > Click on Run, on the top of the window. You should see the dialog presented in the Fig 5. Insert a name for your experiment and define how long it will last. Fig 5. Dialog for resource booking. After you start the experiment, it takes some time to resources become available. When the provisioning process finish, you can click with right button on the VM icon and then click on Open SSH terminal. The VM can be tested using the simple command below: sudo apt update FUTEBOL Consortium Page 13 of 24

14 Three Nodes This is a more advanced tutorial. The example below show a complete RSpec to allocate a three VMs connected through a bridge. <? xml version= '1.0'?> < rspec xmlns= " type= "request" xmlns: emulab = " xmlns: delay = " xmlns: jfed-command = " xmlns: client = " xmlns: jfed-ssh-keys = " xmlns: jfed = " xmlns: sharedvlan = " xmlns: xsi = " xsi :schemalocation= " " > < node client_id= "node0" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "vm-m1.small" > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+img-ubuntu16-cloud" /> </ sliver_type > < location xmlns= " x= "59.0" y= " " /> < interface client_id= "node0:eth0" > < ip address= " " netmask= " " type= "ipv4" /> </ interface > </ node > < node client_id= "node1" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "vm-m1.small" > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+img-ubuntu16-cloud" /> </ sliver_type > < location xmlns= " x= " " y= " " /> < interface client_id= "node1:eth0" > < ip address= " " netmask= " " type= "ipv4" /> </ interface > </ node > < node client_id= "node2" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "vm-m1.small" > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+img-ubuntu16-cloud" /> </ sliver_type > < location xmlns= " x= " " y= "25.0" /> < interface client_id= "node2:eth0" > < ip address= " " netmask= " " type= "ipv4" /> </ interface > </ node > < node client_id= "bridge0" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "bridge" /> < location xmlns= " x= " " y= " " /> < interface client_id= "bridge0:eth0" /> FUTEBOL Consortium Page 14 of 24

15 < interface client_id= "bridge0:eth1" /> < interface client_id= "bridge0:eth2" /> </ node > < link client_id= "link1" > < component_manager name= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" /> < interface_ref client_id= "node0:eth0" /> < interface_ref client_id= "bridge0:eth1" /> < link_type name= "lan" /> </ link > < link client_id= "link0" > < component_manager name= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" /> < interface_ref client_id= "node1:eth0" /> < interface_ref client_id= "bridge0:eth2" /> </ link > < link client_id= "link2" > < component_manager name= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" /> < interface_ref client_id= "node2:eth0" /> < interface_ref client_id= "bridge0:eth0" /> </ link > </ rspec > Paste the content above in the RSpec Editor tab on jfed. If you switch to the Topology Editor tab, you will see the following. Fig 6. An experiment with three nodes and one bridge. FUTEBOL Consortium Page 15 of 24

16 Start the experiment. After the allocation, open a terminal for each node. Let's test if the bridge works. On the node1 and node2 run the following command: sudo tcpdump -i ens3 src host The command above make the nodes capture any traffic passing on the interface ens3 (that we configured in the RSpec as eth0) from the node0. On the node0 run the following command: ping The command above makes the node send ping packets to node1. If everything went well, you should see node1 capturing packets while node2 do not captured any packet. FUTEBOL Consortium Page 16 of 24

17 4. Experiments with Virtual Network Functions This section describes how to allocate Virtual Network Functions (VNFs) and how to run simple experiments to check the operability of the resources Virtual Network Functions RSpec Description There are two ways to run an experiment using VNFs. The simplest way is to choose one template (VNF descriptor) available in the testbed. Such descriptors are TOSCA files specifying the VMs, the topology and the policies used to regulate the scale of the VNF. To check which descriptors are available in the UFES testbed, take a look at: The example below presents a RSPEC for a VNF descriptor: < nfv client_id= " my_vnf " component_manager_id= "urn:publicid:idn+futebolufes+authority+am" exclusive= "false" > < sliver_type name= " vnf " > < template name= " urn:publicid:idn+futebol.ufes.br+vnf+http_server.yaml " /> </ sliver_type > </ nfv > The VNF is defined in a nfv tag. The attribute client_id allows user to choose a friendly name for his/her VNF. The sliver_type tag must be vnf. Nested in the sliver_type tag, user should insert a template tag to specify which descriptor should be used to instantiate the operating system for the VM. The other way to make experiments using virtual network functions is to allocate a quota of raw resources in the cloud (e.g., an amount of vcpu, RAM memory and storage capacity). The quota represents a project (a.k.a., tenant ) inside the OpenStack. It provides the flexibility needed to create custom VNFs and instantiate VNFs dynamically (after the allocation and provisioning of the slice of the cloud). The example below presents a RSPEC which describes a quota of cloud resources: FUTEBOL Consortium Page 17 of 24

18 < vim client_id= " vim0 " component_manager_id= "urn:publicid:idn+futebolufes+authority+am" exclusive= "false" > < sliver_type name= " tenant " > < properties disk= " 120 " ram= " 5 " vcpu= " 3 " /> </ sliver_type > </ vim > The quota is defined in a vim tag. The attribute client_id allows user to choose a friendly name for the quota. The sliver_type tag must be tenant. Nested in the sliver_type tag, user should insert a properties tag to specify the amount of vcpu, RAM memory and storage capacity to be reserved for the experiment. The amount of memory and storage should be describe in Gigabytes. The user can mix VNF with the quota. However, each RSpec can contain, at most, one vim tag. Note: Besides to the use of VNF and/or quota, the user should include in the RSpec one VM which uses a disk image prepared for the orchestration of the VNF resources. Such VM is useful to enable the user to manage the VNF s life-cycle and access the instances (via SSH). More details will be given on the experiments tutorials. The example below shows an RSPEC that describes the orchestration VM: < node client_id= " orchestrator " exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= " vm-m1.small " > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+nfv- orchestrator " /> </ sliver_type > </ node > Examples of a VNF Experiments Using a VNF template In this scenario, the user will instantiate a VNF defined in of of the templates available in the testbed. This scenario demonstrates how the user can play with NFV with a high degree of automation and no need of deep knowledge on OpenStack or NFV. The description the VNF used in this tutorial is described below. FUTEBOL Consortium Page 18 of 24

19 tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0 description: Demo example metadata: template_name: vnf-demo topology_template: node_templates: VDU1: type: tosca.nodes.nfv.vdu.tacker capabilities: nfv_compute: properties: num_cpus: 1 mem_size: 512 MB disk_size: 1 GB properties: image: cirros x86_64-disk availability_zone: nova mgmt_driver: noop CP11: type: tosca.nodes.nfv.cp.tacker properties: management: true order: 0 anti_spoofing_protection: false requirements: - virtuallink: node: VL1 - virtualbinding: node: VDU1 VL1: type: tosca.nodes.nfv.vl properties: network_name: net_mgmt vendor: Tacker The first step is to open jfed and log in. Then go to RSpec Editor tab. Paste the following content in the editor. FUTEBOL Consortium Page 19 of 24

20 <? xml version= '1.0'?> < rspec xmlns= " type= "request" generated_by= "jfed RSpec Editor" generated= " T16:14: :00" xmlns: emulab = " xmlns: delay = " xmlns: jfed-command = " xmlns: client = " xmlns: jfed-ssh-keys = " xmlns: jfed = " xmlns: sharedvlan = " xmlns: xsi = " xsi :schemalocation= " " > < nfv client_id= "my_vnf" component_manager_id= "urn:publicid:idn+futebolufes+authority+am" exclusive= "false" > < sliver_type name= "vnf" > < template name= "vnf-demo.yaml" /> </ sliver_type > </ nfv > < node client_id= "orchestrator" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" exclusive= "false" > < sliver_type name= "vm-m1.small" > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+nfv-orchestrator" /> </ sliver_type > </ node > </ rspec > Start the experiment. After the allocation, go to Topology Viewer tab. You will see the following. FUTEBOL Consortium Page 20 of 24

21 Fig 7. The Topology Viewer tab. Click with right button on the VM icon and then click on Open SSH terminal. You can can view the IP addresses of the VMs composing the VNF using the simple command below: tacker vnf-list The command above interacts with OpenStack service responsible for the management of VNFs. You will see an output like this: [ { "status": "ACTIVE", "vnfd_id": " b-7f28-49f7-89e5-26e48702f835", "vim_id": "729ac2c7-664d-4ac4-937b-d36577b907a6", FUTEBOL Consortium Page 21 of 24

22 ] } "mgmt_url": "{\"VDU1\": \" \"}", "id": "66926cdd-56f acff-a8dd70fb9070", "name": "my_vnf" The value of the field mgmt_url contains the name of the VMs composing the VNf and its respective IP addresses. So you can access VDU1 (via SSH) Using a quota of the cloud resources This is a more advanced tutorial. In this scenario, the user will instantiate a project in the cloud and, after the allocation, will create a custom VNF. This scenario demonstrates how the user can play with NFV with a high degree of automation and no need of deep knowledge on OpenStack or NFV. The description the VNF used in this tutorial is described below. <? xml version= '1.0'?> < rspec xmlns= " type= "request" generated_by= "jfed RSpec Editor" generated= " T12:26: :00" xmlns: emulab = " xmlns: delay = " xmlns: jfed-command = " xmlns: client = " xmlns: jfed-ssh-keys = " xmlns: jfed = " xmlns: sharedvlan = " xmlns: xsi = " xsi :schemalocation= " > < node client_id= "orchestrator" exclusive= "false" component_manager_id= "urn:publicid:idn+futebol.inf.ufes.br+authority+cm" > < sliver_type name= "vm-m1.small" > < disk_image name= "urn:publicid:idn+futebol.inf.ufes.br+image+nfv-orchestrator" /> </ sliver_type > < location xmlns= " x= "50.0" y= "25.0" /> </ node > < vim client_id= "vim0" component_manager_id= "urn:publicid:idn+futebolufes+authority+am" exclusive= "false" > < sliver_type name= "tenant" > < properties disk= "120" ram= "16" vcpu= "8" /> </ sliver_type > </ vim > </ rspec > FUTEBOL Consortium Page 22 of 24

23 Paste the content above in the RSpec Editor tab in jfed. Start the experiment. After the allocation, go to the Topology Viewer Tab and open the SSH terminal for the orchestration VM. To create a custom VNF, we will use the following TOSCA file (VNF descriptor): tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0 description: simple-vnf metadata: template_name: simple-vnf topology_template: node_templates: VDU1: type: tosca.nodes.nfv.vdu.tacker properties: image: ubuntu16-cloud flavor: m1.small availability_zone: nova mgmt_driver: noop metadata: { metering.server_group: SG1} CP1: type: tosca.nodes.nfv.cp.tacker properties: management: true anti_spoofing_protection: false requirements: - virtuallink: node: VL1 - virtualbinding: node: VDU1 VL1: type: tosca.nodes.nfv.vl properties: network_name: net0 vendor: Tacker policies: - SP1: type: tosca.policies.tacker.scaling targets: [VDU1] properties: increment: 1 cooldown: 120 min_instances: 1 max_instances: 5 default_instances: 1 - vdu_cpu_usage_monitoring_policy: type: tosca.policies.tacker.alarming triggers: vdu_hcpu_usage_scaling_out: event_type: FUTEBOL Consortium Page 23 of 24

24 type: tosca.events.resource.utilization implementation: ceilometer meter_name: cpu_util condition: threshold: 70 constraint: utilization greater_than 30% period: 300 evaluations: 1 method: mean resource_type: instance comparison_operator: gt metadata: SG1 action: [SP1] Copy the content above to the orchestration VM (use simple-vnf.yaml as filename). The command below creates a new VNF using the file simple-vnf.yaml. tacker vnf-create --vnfd-template simple-vnf.yaml my-custom-vnf The command above interacts with Openstack to create the custom VNF. The option --vnfd-template indicates that use want to create a VNF based on the description given in the file simple-vnf.yaml. The parameter represented by my-custom-vnf is the name of the VNF instantiated. To see what are the VNFs running on the project, use the command below. If the creation of the VNF was successful, you will see my-custom-vnf on the list. tacker vnf-list To see more details of my-custom-vnf, use the command below: tacker vnf-show my-custom-vnf To delete of my-custom-vnf, use the command below: tacker vnf-delete my-custom-vnf FUTEBOL Consortium Page 24 of 24