To all our friends and partners!
Month: December 2012
Last Friday Philipp from the ICCLab gave a presentation about SDN and OpenFlow to ZHAW master students. The big difference is that the average age of the students is higher and all of them are working for many years in the field of IT. Furthermore, most of them have a leading position in their daily work. The content of the presentation is not that detailed an covers basically the two whitepapers from the ONF and openflowhub.org about SDN and OpenFlow. We also talked about the available products in the field of OpenFlow controllers and why SDN in general is such an important thing for the datacenter providers, ISP’s or Carrier Ethernet.
The discussion we had after the presentation contained also some critical voices that addressed problems like:
- OK, we are vendor independent and have full control over the network but this means also, that we are responsible for it.
- Is it not easier for SME’s to have a ready made network component from e.g. Cisco instead of programming the logic by themselves?
- The centralized network controller looks like a single point of failure and without the network, most business applications will not work.
- Will the programmed network logic inside the controller not bee a huge bunch of code that was before distributed and small on every device?
Of course, we can answer the questions and solve these problems with the SDN paradigm. But the conclusion for us is that we can only get these people on board if we not only talk about SDN concepts but present demonstrators. What we need at this point are:
- Concrete working pieces of code and open working network logic that is tested and maintained as e.g. spanning-tree modules.
- Testbeds and use-cases for implementation, migration and operation.
- Fully functional and easy to implement network controller modules.
Such people as the master students are needed because they are and/or will be the decision makers. It is also not enough to say: “Look, Google uses it in their wide area network.”
Integration and migration of our existing network infrastructure is exactly what we are planning to do at the ICCLab. I hope that more people will share their knowledge and experience about a successful migration of their classical network to a SDN based infrastructure.
In our lab we have the need to have one environment which is running OpenStack Essex and another which is running OpenStack Folsom. Here’s a guide on how we setup our infrastructure so we can support the two environments in parallel.
To install Essex using Puppet/Foreman please follow the guides:
- [OpenStack Puppet Part1](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-one/),
- [OpenStack Puppet Part2](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-two/),
- [OpenStack Puppet/Foreman](http://www.cloudcomp.ch/2012/07/foreman-puppet-and-openstack/)
Here it is only described how to integrate OpenStack Foslom with Puppet/Foreman. It is assumed that Puppet and Foreman are already set up according to the articles mentioned above.
2 environments will be created: `stable` and `research`. In the stable environment are the puppet classes for Essex and in the research environment the Folsom classes.
Create following directories:
[gist id=4147331]
Add the research and stable module path to /etc/puppet/puppet.conf
[gist id=4147341]
Clone Folsom classes:
[gist id=4147352]
Add compute.pp controller.pp, all-in-one.pp, params.pp
[gist id=4292299]
While applying controller.pp classes I encountered following error:
[gist id=4147369]
This issue is desribed [here](https://github.com/puppetlabs/puppetlabs-horizon/pull/26).
To overcome these issues add `include apache` in:
[gist id=4147377]
According to a [previous article](http://www.cloudcomp.ch/2012/07/foreman-puppet-and-openstack/) describing an issue with multiple environments, executing these steps is required:
[gist id=4147408]
After that in Foreman you can create new hostgroups and import the newly added classes (More – Puppet Classes – Import form local smart proxy).
Define stable and research environment and 3 hostgroups in the research environment: os-worker, os-controller, ow-aio.
Next assign the icclab::compute and icclab::params class to the worker hostgroup, icclab::controller and icclab::params class to the controller hostgroup and icclab::aio and icclab::params to the aio hostgroup.
Since we are using Ubuntu 12.04 it is required to add the Folsom repository to your installation. In order to do that create a new provisioning template. Copy the existing one and add line 14-18.
Name: Preseed Default Finish (Research)
Kind: finish
[gist id=4292436]
Please also consider the interface settings in line 1-7. Without these setting it was not possible to ping nor ssh VMs running on different physical nodes. This hint was found [here](http://www.mirantis.com/blog/openstack-networking-single-host-flatdhcpmanager/#network-configuration)
After that click on Association, select Ubuntu 12.04 and assign the research hostgroup and environment.
In our installation we got this error in the VM console log:
[gist id=4292393]
In our case it was due to wrongly configured iptables by open stack.
Adding the parameters metadata_host and routing_source_ip to nova.conf on the nova-network nodes has solved the issue. To make this permanent with puppet add Line 4, 34 and 35 in `/etc/puppet/modules/research/nova/manifests/compute.pp`:
[gist id=4292497]
With these steps followed you should then be able to go about provisioning your physical hosts across both puppet environments. In the next article we’ll show how we’ve segmented our network and what will be the next steps in progressing our network architecture.
Subscribe
Subscribe
Recent Comments