Dialogic Blog

Real-World OPNFV Implementation – Traps and Tips (OPNFV Demystified  Part 5)

by John Hermanski

Aug 4, 2016 10:08:16 AM

Real-World OPNFV Implementation – Traps and Tips (OPNFV Demystified  Part 5)

In the previous blog on OPNFV Demystified I described deploying OPNFV on a collection of rack mount servers (RMS) using Fuel as the installer of choice. I want to continue by going over the areas that may need some clarification, traps I fell into, and mention a few things that I really want to emphasize as I went through the deployment process.

  • OpenDaylight - I chose to use OpenDaylight as a Neutron networking plugin. It’s a well-known Software Defined Networking (SDN) package that has been around for quite some time. You will not need to deal with it directly, as Neutron using its own API or Horizon will be your primary virtual networking interface. I do have some concerns over its use in managing L3 traffic (Recommended with OPNFV, and set on the Settings/Other/OpenDaylight plug-in screen). I was experiencing problems with reaching two of the routers in my virtual network after deploying with that option set. I had to redeploy with it turned off. My dysfunctional routers were then cured.
  • Networks Settings
    • The public network CIDR must match your actual network that is accessed through your ToR switch. The other internal networks – Storage, Management, Private, Internal – are probably best left as is with indicating their status as private.
    • The VLAN tag for the Public network must match the VLAN ID used by the ToR switch or the switch will discard all packets for that network.
    • Public floating IP address attached to running instances will come out of a pool that is part of the public address network space. The IP range set for the public network will just be used by OpenStack nodes; divide them up so that each guest VM you are likely to be concurrently running has the option for attaching a floating IP to get to the outside world.
    • Always, always run the Network Verification Connectivity Check before launching a deployment. You do not have a prayer of it succeeding unless your network verification is successful. Note that your nodes must be set up before doing this.
  • Logs
    • I have not found the Logs display function in Fuel to be very useful. Yes, it will get you to all logs on all systems. But unless you really know where you are going and why you want to look there, you will get lost.
    • Instead, when trolling logs for some detailed clues on why your deployment has failed, your best bet is to start by ssh’ing to the Fuel master itself. Since this system uses Docker containers to segment its various functions, you will want to go to /var/log/docker-logs. There you will see directories for astute, cobbler, puppet, nailgun and other components involved in the OpenStack deployment. Using grep and other Linux command line utilities will help in detailing the failure. It may then be necessary to go to the OpenStack node where the error originated to get further clues.
    • Remember that OPNFV has an active user forum. You will want to post a question there if/when you get stumped.
  • Storage – if you are not doing high availability using multiple redundant nodes, you will need to set the “Ceph object replication factor” to 1 in Settings/Storage/Storage Backends or deployment quickly fails.
  • Security – it may be less painful to reset any and all passwords from their default than listen to Fuel and OpenStack incessantly complain that you haven’t done so.
  • Nodes
    • Setting network interfaces is straightforward/easy. Just drag the networks into the correct interfaces.
    • Setting disk allocation is less so. The system partition can be safely left to its default. You will need to make some educated guesses as to how much space will be needed for logging (on by default) and how many running instances you will likely have as opposed to stored images. You may not get it right on the first try. I’m still in the educated guess stage.
  • Dashboard – besides the information displayed, you may (unfortunately) find the “Reset Environment” function useful. This will retain the environment settings that you have labored to get right and allow you to try it all again from scratch when you have made a correction after a failed deployment.
  • Health Check – when you have a successful deployment, go for it. All of them. Some don’t apply, but you will be told which ones. If they pass, you can go forth reasonably well assured that you have a functioning OpenStack deployment.

That’s all for this blog installment. You should be good to give your OPNFV installation and deployment a shot. Next time, I’ll talk some about doing the same in a Blade Server environment. While the basic deployment is really the same, the setup and networking are more complicated.

This is part 5 of the "OPNFV Demystified" blog series. The next part of the blog series will be posted on Thursday morning each week.

Check out the other posts in this series.

Topics: NFV/SDN & Cloud, Guides: How-to's, Infographics, and more