Cloud Integration with OpenStack (OVSDB/NetVirt)

Transcription

1 Cloud Integration with OpenStack (OVSDB/NetVirt) Background 2 Preconditions 3 Main Success Scenario: 3 Step-by-step Tutorial 4 OpenDaylight s Required Features 5 OpenStack Configuration for OpenDaylight 6 Stacking and Creating Networks: 7 OVS instance and br-int 8 Use-Case Network Topology 14 OpenStack Horizon 14 OpenDaylight DLUX 15 Testing the Use Case 17

2 Background OpenStack is a popular cloud platform covering compute, storage and network management. OpenStack can use OpenDaylight as its network management provider through the Modular Layer 2 (ML2) and the networking-odl plug-in. Moreover, OpenStack can use OpenDaylight to manage L3 networking and floating IPs. OpenDaylight manages the network flows for the OpenStack's control and compute nodes via OpenFlow southbound plugin and OVSDB southbound plugin. In this use-case we will use OpenStack and OpenDaylight to create a Virtual Extensible LAN (VxLAN) network between 4 hosts (VMs). We will create one OpenStack control/compute node and another OpenStack compute node that will both be running along with OpenDaylight. We will create 2 VxLANs (vx-net0, vx-net1) as internal networks and another VxLAN (ext-net) as an external network, 1 router and 4 VMs (vmvx 01,02,11,12). The following diagram shows the network topology: The purpose of this use-case is to show that the integration between OpenStack and OpenDaylight allows seamless communication between the VMs and is more efficient with respect to managing the underlying network. The diagram on the following page shows the underlying network component of our use-case.

3 Preconditions We assume that the reader is familiar with OpenStack modules, terminologies and commands (nova and neutron). OpenDaylight Boron release: Download the latest OpenDaylight distribution from VirtualBox: Download VirtualBox on your host machine and install it from netvirt_mitaka_boron.ova: Download the prepared virtual machines OVA image file from Main Success Scenario:

4 The reader will be able to run OpenStack's control and compute nodes as well as OpenDaylight to establish the use-case. At the end, the reader should be able to test the connections between the VMs using a ping command. Step-by-step Tutorial The OVA image provides three VMs: 1. OpenStack control devstack OvS CentOS 7 2. OpenStack compute devstack OvS CentOS 7 3. Router for external access CentOS 6.5 Open VirtualBox s preferences (Ctrl-G) and select the network list on the left. Select the host-only networks tab. Make sure you have a host-only network titled 'vboxnet0'. If not, please click the green + button. Click on the edit (screw) button and set the host-network driver configuration to 'vboxnet0' as shown below.

5 Use the VirtualBox application to import (Control/Command+I) the OVA image file. VirtualBox will take around 5 mins to load the three VMs. While VirtualBox loads the VMs, we will start the OpenDaylight distribution. OpenDaylight s Required Features On the host machine, go to the OpenDaylight distribution directory, extract it and run the following commands: $ cd distribution-karaf boron-sr2/ $./bin/karaf Apache Karaf starting up. Press Enter to open the shell now...100% [========================================================================] Karaf started in 4s. Bundle stats: 64 active, 64 total... \ \ \ \.. / _ / \\ \_/ \ / \ \\ \< / \ \ \ / \ _> > / \ ` \/ \\ _ / /_/ > Y \ \ / / \ > / ( / / \ / / \/ \/ \/ \/ \/\/ / / \/

6 Hit ' <tab> ' for a list of available commands and ' [cmd] --help ' for help on a specific command. Hit ' <ctrl-d> ' or type ' system:shutdown ' or ' logout ' to shutdown OpenDaylight. root> In the OpenDaylight Karaf console, you will install the required Netvirt and OpenStack features (odl-netvirt-openstack odl-netvirt-ui) Use the following command to install them: opendaylight-user@root>feature:install odl-netvirt-openstack odl-netvirt-ui OpenStack Configuration for OpenDaylight Back in the VirtualBox, start the odl31-control_mitaka VM, odl32-compute_mitaka VM and router-node VM. Note: the credential for all VMs are username:odl password:odl You can use ssh to access to VMs. $ ssh odl@ $ ssh odl@ At the odl31-control_mitaka VM, you will find the devstack source under the /opt/devstack/ directory. Navigate to the devstack source directory and open the local.conf file using the following command: $ cd /opt/devstack/ $ vi /opt/devstack/local.conf Note: the local.conf provides different sets of configuration based on your desired deployment. In our use-case, we will use OpenDaylight as an external SDN controller outside of the OpenStack nodes. First, un-comment enable_service odl-compute odl-neutron and comment out enable_service odl-server odl-compute: # enable one of the two below: # the first is external which assumes the user has ODL already running # make sure to set the ODL_MGR_IP and ODL_PORT because we run in manual mode

7 enable_service odl-compute odl-neutron # or use the allinone where devstack will download (if online) and start ODL # enable_service odl-server odl-compute As we will use the external OpenDaylight controller, un-comment the ODL_PORT, ODL_MGR_IP and comment out ODL_USE_EXISTING_JAVA, ODL_NETVIRT_KARAF_FEATURE and ODL_RELEASE enable_plugin networking-odl stable/mitaka # PORT and IP are only needed if using manual mode with external ODL. allinone uses defaults. ODL_MODE=manual ODL_PORT=8080 ODL_MGR_IP= NEUTRON_CREATE_INITIAL_NETWORKS=False ODL_PROVIDER_MAPPINGS=public:eth2 SKIP_OVS_INSTALL=True #ODL_USING_EXISTING_JAVA=True #ODL_JAVA_MAX_MEM=2048m #ODL_NETVIRT_KARAF_FEATURE=odl-netvirt-openstack #ODL_RELEASE=boron-snapshot At the odl32-compute_mitaka VM, open the local.conf file and uncomment the ODL_MGR_IP and ODL_PORT ODL_MGR_IP= ODL_PORT=8080 Stacking and Creating Networks: We will now start stacking the environment. In both VMs (odl31-control_mitaka VM and odl32-compute_mitaka) run the following: $ /opt/devstack/stack.sh Note: it will take around 10 minutes to finish the stacking. While you are waiting for the stacking process to finish, you may see at the console that "waiting for bridge br-int to be available" then the stacking fails. It could happen in both VMs (odl31-control_mitaka VM and odl32-compute_mitaka). In order to fix the stacking failure, do the following: open another console to the odl31-control/odl32-compute VM and run the following commands.

8 $ ssh $ /opt/devstack/unstack.sh $ /opt/devstack/stack.sh Keep watching the console. When the console stops at the following message: "waiting for bridge br-int to be available", go to the first odl31-control VM console and run the following command. $ sudo ovs-vsctl add-br br-int Note: this will enable the stacking process to continue as normal until the end. After the stacking is successfully complete in both VMs, we will create the VxLAN networks and spawn 4 VMs. At the odl31-control VM, run the following command to get the OpenStack's admin user privilege: $ source /opt/devstack/openrc admin admin OVS instance and br-int Before starting to build the use-case network topology, let's examine the OpenStack nodes OVS instance. Run the following command in the odl31-control_mitaka VM: $ sudo ovs-vsctl show be3d a5-447d-b207-7eb9d71a788a Manager "tcp: :6640" is_connected: true Bridge br-int Controller "tcp: :6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port "eth2" Interface "eth2" ovs_version: "2.5.1" As you can see, the OVS instance is managed by the OpenDaylight host ( ). The virtual network interface "eth3" is used to connect the OpenStack nodes to OpenDaylight. The

9 bridge "br-int" has "eth2" attached as the external network interface and "eth1" attached as the internal network interface. You can consider the "eth3" communication as the control network and both the "eth1" and "eth2" as the data network. The following diagram shows the initial state of the OVS instance at the OpenStack Nodes: You can check the initial flow rules that are created by OpenDaylight by running the following command in the odl131-control_mitaka VM: $ sudo ovs-ofctl --protocol=openflow13 dump-flows br-int Click the following link for more information about the flow rules and OpenDaylight netvirt: NetVirt Pipeline. Now we will create our use-case network topology. At the odl31-control_mitaka VM, execute the os_doitall.sh script by using the following. It should take around 3-5 minutes to completely create the network. $ /opt/tools/os_doitall.sh The os_doitall.sh script internally executing other scripts that we created to distinguish between the different components in our use-case network. Run the following command to open os_doitall.sh script: $ vi /opt/tools/os_doitall.sh #!/bin/bash

10 source /opt/devstack/openrc admin admin /opt/tools/os_addnano.sh sleep 1 /opt/tools/os_addadminkey.sh sleep 1 /opt/tools/os_addnet0.sh sleep 5 /opt/tools/os_addvms0.sh sleep 5 /opt/tools/os_addnet1.sh sleep 5 /opt/tools/os_addvms1.sh sleep 5 /opt/tools/os_addrtr.sh sleep 5 /opt/tools/os_addextnet.sh sleep 5 /opt/tools/os_addfloatingips.sh #sleep 1 #/opt/tools/os_addsecuritygroups.sh Now we will explain the steps and OpenStack commands we used to create the network. If you do not want to go into the following OpenStack command details, you can skip to the Use Case Network Topology section. The os_addnano.sh and os_addadminkey.sh scripts are used to create the nano flavor of the VMs that we will use as the network hosts in our use-case, and establish a ssh keypair to be able to access it later. $ nova flavor-create m1.nano auto $ nova keypair-add --pub-key ~/.ssh/id_rsa.pub admin_key $ nova keypair-list os_addnet0.sh and os_addvms0.sh scripts are used to create the vx-net0 and vx-subnet0 networks that attach "vmvx01" and "vmvx02" to vx-subnet0 $ neutron net-create vx-net0 --provider:network_type vxlan --provider:segmentation_id 1501 $ neutron subnet-create vx-net /24 --name vx-subnet0 --dns-nameserver $ nova boot --poll --flavor m1.nano --image $(nova image-list grep 'uec\s' awk '{print $2}' tail -1) --nic net-id=$(neutron net-list grep -w vx-net0 awk '{print $2}') vmvx01

11 --availability-zone=nova:odl31 --key-name admin_key $ nova boot --poll --flavor m1.nano --image $(nova image-list grep 'uec\s' awk '{print $2}' tail -1) --nic net-id=$(neutron net-list grep -w vx-net0 awk '{print $2}') vmvx02 --availability-zone=nova:odl32 --key-name admin_key If we take a snapshot of the OVS instance at both VMs (odl31-control_mitaka and odl32-compute_mitaka), br-int will be as follows: As you can see, contrary to the initial state of the OVS instance, there are now 2 taps created (dhcp client tap and vmx01 tap) and they re attached to br-int in the odl31-control VM, along with another tap created (vmx02 tap) at the odl32-compute VM that s attached to br-int. os_addnet1.sh and os_addvms1.sh scripts are used to create the vx-net1 and vx-subnet1 networks then attach "vmvx11" and "vmvx12" to vx-subnet1 $ neutron net-create vx-net1 --provider:network_type vxlan --provider:segmentation_id 1501 $ neutron subnet-create vx-net /24 --name vx-subnet1 --dns-nameserver $ nova boot --poll --flavor m1.nano --image $(nova image-list grep 'uec\s' awk '{print $2}' tail -1) --nic net-id=$(neutron net-list grep -w vx-net1 awk '{print $2}') vmvx11 --availability-zone=nova:odl31 --key-name admin_key $ nova boot --poll --flavor m1.nano --image $(nova image-list grep 'uec\s' awk '{print $2}' tail -1) --nic net-id=$(neutron net-list grep -w vx-net1 awk '{print $2}') vmvx12

12 --availability-zone=nova:odl32 --key-name admin_key os_addrtr.sh script is used to create the external router ext-rtr and attach the subnets (vx-subnet0 and vx-subnet1) to it. $ neutron router-create ext-rtr $ neutron router-interface-add ext-rtr vx-subnet0 $ neutron router-interface-add ext-rtr vx-subnet1 os_addextnet.sh script is used to create the external network ext-net and set it as a gateway to our router, ext-rtr. $ neutron net-create ext-net --router:external --provider:physical_network public --provider:network_type flat $ neutron subnet-create --name ext-subnet --allocation-pool start= ,end= disable-dhcp --gateway ext-net /24 $ neutron router-gateway-set ext-rtr ext-net Finally, os_addfloatingips.sh script is used to create floating IPs for all the VMs (vmx01, vmx02, vmx11 and vmx12) so they can be accessible through the external network: #!/bin/bash for vm in vmvx01 vmvx02 vmvx11 vmvx12; do vm_id=$(nova list grep $vm awk '{print $2}') port_id=$(neutron port-list -c id -c fixed_ips -- --device_id $vm_id grep subnet_id awk '{print $2}') neutron floatingip-create --port_id $port_id ext-net done; $ neutron floatingip-list Check the OVS instance at the odl31-control_mitaka VM by using the following command: $ sudo ovs-vsctl show

13 7f59a47a-9e4e-42b1-a3b1-6102b37f7314 Manager "tcp: :6640" is_connected: true Bridge br-int Controller "tcp: :6653" is_connected: true fail_mode: secure Port "tapf6e6da6c-e9" Interface "tapf6e6da6c-e9" type: internal Port br-int Interface br-int type: internal Port "tuna2af174306b" Interface "tuna2af174306b" type: vxlan options: {key=flow, local_ip=" ", remote_ip=" "} Port "tap971a " Interface "tap971a " Port "tap2a e" Interface "tap2a e" Port "tape83f636e-83" Interface "tape83f636e-83" type: internal Port "eth2" Interface "eth2" ovs_version: "2.5.1" Check the OVS instance at the odl32-compute_mitaka VM by using the following command: $ sudo ovs-vsctl show 5f6af f9-979b-c2349a0467ba Manager "tcp: :6640" is_connected: true Bridge br-int Controller "tcp: :6653" is_connected: true fail_mode: secure Port "eth2" Interface "eth2" Port "tap0e38c88e-bd" Interface "tap0e38c88e-bd"

14 Port "tapb850a9ab-44" Interface "tapb850a9ab-44" Port br-int Interface br-int type: internal Port "tund395dc05f98" Interface "tund395dc05f98" type: vxlan options: {key=flow, local_ip=" ", remote_ip=" "} ovs_version: "2.5.1" As you can see in the following diagram, vmx12 and vmx11 are in the same network but they are hosted in two different host VMs, odl31-control_mitaka and odl32-compute_mitaka. OpenDaylight manages the networking between the different hosts by constructing the flow rules pipeline we mentioned at the beginning. Check the flow rules of br-int in both VMs using the following command. $ sudo ovs-ofctl --protocol=openflow13 dump-flows br-int Use-Case Network Topology

15 OpenStack Horizon By using OpenStack Horizon, you can see the created network topology and VMs. Open your browser and enter: Note: Login to Horizon using username:admin and password:admin Note: You should select the admin project from the projects menu to see the network topology we ve created. OpenDaylight DLUX You can also use OpenDaylight DLUX to manage and check the network's underlying components. Open your browser and enter: Note: Login to DLUX using username:admin and password:admin Note: If you are running OpenDaylight Boron SR2 release, you may not be able to see the DLUX user interface due to Bug 7543.

16 You can understand the benefits of using OpenDaylight DLUX, by switching to the 2D View tab and exploring the underlying network elements. For example, you can see the OVS instance information, ports, flow tables and flow rules (as shown below).

17 Testing the Use Case Test the use-case by trying to ping between the VMs. Connect to the VMs and open a console session using Horizon or any other VNC client. Run the following command on the odl_control_mitaka VM to get the console url: $ nova get-vnc-console vmvx01 novnc The output should be similar to the following. You can choose any VM that you want to test the use-case with. Type novnc Url 5c98e30e71a Copy the output URL and paste it into your browser. As you open the browser from the tutorial host machine, change the IP-address at the URL to , then login to the console using the provided user information user-name: cirros, password: cubswin:). The vmvx01 has IP-Address and you should be able to ping vmvx02 with IP-Address

18 $ ping PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=0.070 ms 64 bytes from : icmp_seq=1 ttl=64 time=0.113 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.125 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.093 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.126 ms Ping the created floating IPs (as shown below). $ ping PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=64 time=0.070 ms 64 bytes from : icmp_seq=1 ttl=64 time=0.113 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.125 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.093 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.126 ms Note: for troubleshooting, if you experience the error atkbd serio0: Use 'setkeycodes 00 <keycode>' to make it known when you try to connect to the VMs (vmvx01, vmvx02) console. Do the following to fix it. 1. Open odl31-control_mitaka VM console. 2. Go to the /opt/stack/novnc/ directory and checkout version using the following commands: $ cd /opt/stack/novnc/ $ git checkout v Open a new browser session using the URL you generated from the previous step to access vmvx01 and vmvx02. Your screen should be similar to the following figure in the browser.

19 4. In the odl31-control_mitaka VM and odl32-compute_mitaka VM run: $ /opt/devstack/osreset $ /opt/devstack/unstack.sh $ /opt/devstack/unstack.sh 5. In the odl31-control_mitaka VM run: $ /opt/tools/os_doitall.sh $ nova get-vnc-console vmvx01 novnc 6. In your browser paste the link. Note: you may experiences issues with chrome-based browsers) Conclusion: In this tutorial we established cloud environment using Openstack and used Opendaylight to manage its underlying network elements. In more complex network topology using Opendaylight become mandatory in order to be able to manage the connectivity between different hosts. Opendaylight has the ability to manage the network devices such as Openflow switch and netconf capable switch along with virtual network elements such as OVS that will gives you the ability to manage all the network underlying elements from one single platform.