Adventures with CloudStack and OpenDaylight
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32680 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 20144 / 199
2
3
10
11
12
13
14
17
18
19
23
24
25
27
29
45
46
47
48
49
50
51
52
55
56
57
58
65
67
68
70
72
74
75
76
77
78
79
81
82
84
86
87
89
90
93
94
100
101
102
103
104
106
107
109
110
111
112
113
114
115
119
122
123
124
126
127
128
129
137
139
141
143
145
147
150
154
155
158
161
163
164
165
166
168
171
174
175
176
179
182
183
185
188
190
191
192
194
195
196
00:00
Point cloudMedical imagingAdventure gameThumbnailPresentation of a groupBitStack (abstract data type)Power (physics)Type theoryWeightMultiplication signGraph coloringSocial classComputer animation
00:33
Interface (computing)State of matterElectronic mailing listMereologySign (mathematics)Goodness of fitPhysical systemDimensional analysisMoment (mathematics)Multiplication signProduct (business)Level (video gaming)MultiplicationMathematicsDaylight saving timeConnected spaceDigital rights managementOnline helpVirtual machineSocial classOpen setCodeCommunications protocolWrapper (data mining)DemonOverlay-NetzProjective planeTelecommunicationLebesgue integrationSoftwarePatch (Unix)Classical physicsServer (computing)Computing platformMilitary baseSpectrum (functional analysis)Plane (geometry)Table (information)NumberPosition operatorWebsiteType theoryImplementationTotal S.A.Population densityPoint (geometry)QuicksortConfiguration spaceInteractive televisionSampling (statistics)Process (computing)Perspective (visual)Decision theoryGame controllerAddress spaceIP addressInformationContext awarenessTraffic reportingWhiteboardCloningHypermediaOpen sourcePoint cloudRule of inferenceWordStapeldateiDivisorForcing (mathematics)BitNetwork topologyBootingFlow separationBlogRight angleVirtualizationBlock (periodic table)Computer hardwareDifferent (Kate Ryan album)ArmINTEGRALDataflowArithmetic progressionAuthorizationSinguläres IntegralVector potentialFigurate numberSet (mathematics)Procedural programmingBuffer overflowCollaborationismFitness functionPublic domainBuildingParticle systemStandard deviationGroup actionSystem callData centerSurfaceCore dumpIntegrated development environmentWind tunnelInformation security1 (number)Regular graphAdventure gameArithmetic meanService (economics)CASE <Informatik>Video gamePrisoner's dilemmaPower (physics)Plug-in (computing)Bridging (networking)Wave packetCurvatureFunctional (mathematics)Cartesian coordinate systemCategory of beingInternet service providerUsabilityClosed setUniqueness quantificationIdentifiabilityRankingEnvelope (mathematics)Entire functionGodFerry CorstenMomentumDenial-of-service attackRevision controlPeer-to-peerDivergenceFreewareAnalytic setException handlingExecution unitSynchronizationInformation privacySummierbarkeitOrder (biology)VarianceAreaBit rateInstance (computer science)Internationalization and localizationConstructor (object-oriented programming)Physical lawPresentation of a groupMusical ensembleFiber bundlePhysicalismSoftware testingHybrid computerModule (mathematics)Speech synthesisVariety (linguistics)DatabaseStability theoryEndliche ModelltheorieSeries (mathematics)Branch (computer science)Phase transitionIterationSoftware developerSemiconductor memoryStack (abstract data type)Virtual LANEmailÜbertragungsfunktionView (database)Generic programmingEnterprise architectureThumbnailNoise (electronics)Lattice (order)Focus (optics)Touch typingFluid staticsVideoconferencingBoss CorporationFeedbackDepth of fieldBroadcasting (networking)SpacetimeTelnetMatching (graph theory)Royal NavySuite (music)Router (computing)2 (number)RoutingBefehlsprozessorStructural loadRepresentational state transferLecture/Conference
Transcript: English(auto-generated)
00:01
OK, I just got the thumbs up, so we can get this show on the road. Everybody's still awake? Hello? Wow! This is pretty awesome for Fosdam, but everybody's still awake. I hope you like it. I chose a black background, so nobody has to look at the really bright colors. I tried to keep the images a bit low, so everybody who has a hangover, like me, should be pretty much OK with the presentation.
00:24
This presentation is an adventure story. And I chose this image to kick it off. It's an adventure story about how I got involved with Apache Cloud Stack. Come skip most of that part, but especially... Five minutes early. Yeah, he gave the thumbs up, so he said, get started.
00:48
So even though we're five minutes early, we get started anyway. Hmm? No, actually no, no.
01:02
I'm a dead serious guy. I don't do jokes. Sorry. Who am I? Well, I'm Hugo. I'm working as a mission critical... mission critical engineer for Schubert Phyllis back in the Netherlands. I'm also part of the project management committee of Apache Cloud Stack.
01:21
I contribute to Open Daylight, especially on the OVSDB part, which I will be telling about today. And actually, if I have some spare time, I try to spend it behind one of my PlayStations. Though, unlucky for me, I don't have that much time for it nowadays, since I'm working on all those projects. If you want to reach me for some reason,
01:41
there's a lot of contact details over there. Please try not to tweet too much during the presentation, otherwise my pocket will keep on buzzing. So what I want to do today is tell a bit how I got involved with the Open Daylight project. Open Daylight is a project there's a lot of noise going about
02:01
about Open Daylight, and yeah, I decided to have a look at what it is, what it can be used for, and especially since I'm working with the Apache Cloud Stack project as well, and my main focus within Apache Cloud Stack is software-defined networking. Open Daylight for me was really interesting to look into. So I'm going to tell you a little bit of background about Apache Cloud Stack, a little bit of background
02:21
about Open Daylight. I'm going to ask a question that everybody should be asking in this room. Why the hell would you want to integrate those two projects? And I'm going to tell a bit about my adventure stories and the adventure part here is what actually happens if you decide to take a step and integrate two projects.
02:41
Apache Cloud Stack Apache Cloud Stack is an IAS offering. It's a cloud management system. It orchestrates your hypervisors it orchestrates your networking and it orchestrates your storage. It's a mainly Java-based project it's been around for quite a long time though it gained the most momentum
03:00
actually when it joined the Apache Software Foundation but it has been existing for quite a while before that. We're currently on the release 4.3 or close to releasing 4.3 pretty stable platform a lot of enterprises actually using it we get a lot of positive feedback both from open source communities but also from commercial parties who are building businesses
03:22
around Cloud Stack. So it's really getting a lot of momentum and one of the things I like about the Apache Cloud Stack bit of software is that it supports a multitude of different hypervisors, networking platforms, etc. We have some of the networking platforms that we support. We support Zero MVP we support Metacor, we support
03:42
Stratosphere, BigSwitch the unlucky part for a lot of people is that most of these offerings are actually commercial offerings and I'm really glad I can actually be here and talk about integrating an open source software-defined networking platform. And that's this one
04:00
that's Open Daylight. Well, actually Open Daylight is a lot more Open Daylight is quite a big project there's a lot of big vendors and a lot of enthusiastic volunteers working on the project and it's really it's more about facilitating the community it's about providing a stable available controller platform that can support a variety of
04:20
software-defined networking tools but also network function virtualization it literally does a lot I listed a few of the things that I've found but yeah there was a session earlier yesterday about application archaeology I think that suits this really dive into it and see what it all supports it's almost impossible to keep up
04:43
everything okay? So the things I've been looking at is maybe at the network virtualization part and then you hit stuff like OpenFlow you hit stuff like OVSDB Virtual Tenant Network opened off but yeah, there's support for the board
05:00
it supports hardware, it supports software switches really a lot of things So when I found Open Daylight and started looking into the project I said okay, there's some serious potential here it has the possibility of working with an open community working with an open source software to basically get
05:21
my needs for Apache Cloud Stack and have them with an open project So that was actually the tricky part So what is it exactly that I need? So then looking at the Apache Cloud Stack networking setup it's the basic of what we do with the networking part of Apache Cloud Stack
05:41
So what do we have in Apache Cloud Stack? So we have basic networking basic networking is basically the old Emerson style networking everything on the big flat IP network, isolated using security groups and some voodoo that deals with filtering MAC addresses etc to make sure you have some kind of tenant isolation
06:02
Then there's the advanced networking it's actually not even as advanced but that's how it's called at the moment but the advanced networking the difference here is that it is layer 2 separation So it's really, you get your own private broadcast domain and actually we're using yeah, I think nowadays it's called Network Function Virtualization
06:21
we use a router construct that deals with all the stuff like routing firewalling, load balancing etc and it sits between your network and the outside world and allows you to make use of its services and also give you some privacy on your own network We support Virtual Private Cloud which is actually almost the same as an isolated network
06:42
except it's a multi-tiered network For me the advanced networking is really the most interesting bit I'm We're not selling any products based on CloudStack, we're not involved with the community we're not selling hardware, anything we're just users of CloudStack For us it's really
07:03
speed up okay So, is this better? Yeah, okay, sorry about that So Let me repeat the basics about networking because it's actually the most important part that we will be talking about for the rest of the presentation
07:21
So there's basic networking separation based on L3 and there's advanced networking where separation based on layer 2 individual broadcast domains And as I was saying, I'm really a user of CloudStack, we use it inside our company for a lot of different purposes and for me the advanced networking is really the interesting thing. We have a lot of networks
07:40
we create networks every five minutes and VLANs just didn't cut it anymore for us So quite a while back we actually switched to using software-defined networking And software-defined networking really fits with the advanced networking model where we can create isolated broadcast domains on any kind of infrastructure without having to rely on switches doing a lot of the VLAN work going into the switches, configuring them
08:02
So we're really a fanatic user about software-defined networking So we're already using it and I was working with the NISTIRA MVP mostly and then I found the Open Daylight project With my hat on As a technology management member committee it was an easy decision
08:21
We need to do something with Open Daylight It's a fantastic project a lot of nice people over there It's supporting just about anything you can find in a networking stack at the moment that's open and available And well as Apache CloudStack, we're a cloud management system, we're basically an orchestrating party
08:41
If there's nothing we can orchestrate with, we're a pretty useless project So orchestrating with Open Daylight means for us that we can actually be part of a bigger, we can expand our ecosystem, we can expand our usability for our users So it's really a good match and it's an open project So that was great
09:00
And one of the other big reasons is that there was a lot of talk about should we be doing something with SDN Of course we had support for software-defined networking vendors already in CloudStack But you want some open solution You want somebody, people can just download, use and build software-defined networking within CloudStack So we already have some support We have support for VXLAN, we have support for GRE
09:21
So basically we're already acting like a bit of a controller But there's people actually more knowledgeable about building controllers We're really good at orchestrating stuff and maybe we should leave the networking control a bit to actually other projects who have the networking people and the know-how and the technology to actually do it And Open Daylight is one such project They really have the knowledgeable people about
09:41
software-defined networking So we can leverage those great minds and get our stuff for free And of course, as everybody here knows it's actually quite fun to do such a project So that's when really for me the fun started I already found Open Daylight I was getting involved and I was like Okay, now I have a project with about 20 sub-projects
10:03
What the hell am I going to support here? So it was really time to sit down and say Okay, what exactly do I want to do? I can just about integrate anything from that Open Daylight, but what's actually useful from a user perspective, what's usable for me to do as a first step in the integration part So I said, okay, my goal is going to be
10:21
I want to have a couple KVM hypervisors and I want to be able to build an overlay network between those hypervisors Really, the bare bones about what it is that virtual networking provides you overlay networking provides for you So I decided, okay, that's going to be pretty easy So it's on to the API
10:41
Okay, that's actually going to be a really tricky bit But I'll explain that later Because then we found the next problem What the, I mean Okay, I said I want KVM support I want to build an overlay network
11:01
There's actually quite a few projects providing overlay networking in Open Daylight There's virtual tenant networking There's Open DOF And there's the open OVSDB plugin that works together with the OpenFlow plugin For me, I selected the OVSDB and OpenFlow plugin Mainly because there's stuff I'm familiar with I'm already used to working with OVSDB
11:21
I'm used to working with OpenFlow So for me, it was something I could understand it I could work with it And it seemed at the time pretty easy to get into How wrong I was? Because it was nowhere near finished I mean, we're currently just about to release our first release of Open Daylight, the hydrogen release
11:42
At the time I joined the project That's a couple of months ago And now it was really in no state to be usable It was a bunch of great minds and a bunch of great ideas and some code But nothing really usable yet So let's get into it
12:00
Before we get into the details Just a bit of a background about what it is we intended to do So in Open Daylight, there was already a lot of support for OpenFlow And OpenFlow is actually a protocol that will basically replace your control plane and your switches So you have the data forwarding plane which actually takes packets from A dumps them on port B
12:20
And then you have the control plane And for those of you who have been in networking There's usually the stuff you configure using Telnet or SSH You tell the switch how to make its decisions on where a packet should go And if you're using software-defined networking it's usually the controller that's going to be telling the switch how to do it and where to forward packets
12:41
And the way the controller tells the switch how to forward packets and what to do with certain packets coming in on port That's the OpenFlow protocol So the OpenFlow protocol is actually a really simple rule-based protocol. You build a table of rules into your switch and a rule can be as simple as 8 packets coming in on port 1. Please tag it with VLAN100
13:01
and send it out on port B Or send it to a controller which is really interesting So you can suddenly send a packet that's coming in on port 1, you can send it to a controller Controller pick it up, look at it make some intelligent decision about where this packet should go and send that conclusion back to the switch The OpenFlow plugin was pretty much already in
13:22
open daylight at the time So it was mostly used to control the hardware as the first step of software-defined networking, controlling your switches from a central controller instead of going into the switch and doing SSH stuff That was already in open daylight
13:41
but the thing missing there is actually the control layer As we now have a lot of hypervisors and we want to do virtual networking on hypervisors there's a layer between the hardware we have in the data center and the VM running on a hypervisor and this layer most often is OpenVSwitch nowadays So OpenVSwitch is a real switch
14:00
in any sense of the world The packet forwarding supports all kinds of open standards but there's one tricky problem with OpenVSwitch is that it has no fixed hardware If you look at a real switch the one you put in your data center it has like 24 ports you can give them a number, port 1, port 24 and it's fairly easy to understand
14:21
if you want to configure something in port 1 you configure it in port 1 If you have OpenVSwitch it's actually far more complex because how many ports do I have? Where are my ports? Where are they? What do they look like? Are they interfaces? Are they bridge ports? Are they patch ports? And that's where the OVSDB interface comes in
14:42
It's like the meta-management system of the OpenVSwitch You can tell it to create a port because if you want to boot a virtual machine it needs a virtual interface and the virtual interface needs to be plugged onto the OpenVSwitch and for that you need a port If you have multiple switches inside your OpenVSwitch and you want to connect them
15:00
you need to create patches between the two ports That's all done using software The software doing it is the OVSDB Daemon and the OVSDB Daemon uses a JSON RPC protocol which is called OVSDB protocol It provides you with centralized management of your OpenVSwitches so you can really configure
15:21
all the stuff you need to configure from a standpoint At the time when I got into the project the OVSDB plugin wasn't really well-defined yet It was a couple of ideas about where we wanted to go where we wanted to take the plugin but a lot of bright ideas
15:41
but no real conclusions yet So That's actually the point where the integration starts to be really interesting Up to that point it was all like Google research and downloading the code doing a lot of git clones trolling through the mailing list archives and seeing what actually happened This was a scary bit about the integration because suddenly I had to talk to a human about this
16:03
It was really a very nice experience Everybody working in open source communities knows that if you join a new community it can be either a very friendly community or it can be a hostile community or it can be a community that completely ignores you In this case I found two people or actually I found a lot of people but two people really stood out I came in touch with Brent Sellersbury
16:21
I don't know if you guys know him better as the name Network Static but if you don't please look up his blog If you ever want to know something about Open vSwitch and software-defined networking it's on his blog and I found Madhu Vensupal and I hope I just pronounced his name right I'm not sure Those guys really welcomed me with open arms
16:41
They sat down, made a lot of time I was on IFC for about an hour talking to these guys and then they said, hey, we're going to open up a Google video call why don't you join and we're going to sit down and really explain what you need to know and how we can help you Before I knew it I was actually part of a community
17:00
In two or three hours time I was part of a community that I've never been part of and that's really a great welcoming community I think that's really part of what open source is all about is being friendly to each other and helping each other out So I had a couple of new friends and we started to sit down and say, okay so what are you guys working on Well, we're working on a lot of things
17:23
For example, one of the discussions we're having is like okay, we want to do integration and they were mainly working on integration with OpenStack and I was working on integration with CloudStack and we're having discussions like where actually do we want to integrate There's multiple levels available in OpenDaylight OpenDaylight is such a flexible platform
17:42
you can integrate on the very low level and with low level OVSDB plugin really meant like OpenDaylight being a portal into OVSDB like a wrapper it would just be a wrapper between OVSDB protocol and the REST API provided by OpenDaylight allowing me direct interaction with the OVSDB
18:01
On the other hand, there were also various levels of higher layer APIs So the first question everybody asked and we asked the same question from the OpenStack Neutron perspective and from CloudStack perspective What is it we actually want to do? Where do we want to integrate?
18:21
So there was a lot of fun discussions it was really about what is the purpose of each project and finally we sort of sat down and decided okay, we want the cloud management systems to do just that cloud management leave them to do the orchestration bit leave them to actually select what needs to be done and then trust the OpenDaylight
18:41
part to actually do the stuff I don't need to know how you create a port in OVSDB I don't need to know that if you create a network interface you first need to create a port and then attach it to the interface That's actually not that interesting to me I just want to make sure that if I create a virtual machine and I tell something that I need a port all the relevant parts will be done
19:04
And the next thing was okay, so now we've decided that we're going to put a lot of intelligence or at least a lot of the day-to-day heavy lifting in the OpenDaylight OVSDB plugin Where are we going to put the brains? Who's going to be responsible for knowing what to do? Who's going to be the owner of the current state?
19:23
Again, that's an interesting discussion Cloud management systems traditionally have a view like they own the world Cloud management system is the boss it knows it and every other system has to comply to their wishes Might be a very good idea because Cloud management system is supposed to have a very overall
19:41
very broad view about your entire setup but on the other hand stuff like OpenDaylight it knows a lot about the network So where do we actually put the real interesting data like what are the connected hypervisors who's in charge of knowing what kind of switches are available, who knows which ports are enabled and which ports have a certain
20:01
administrative state We spend a lot of time discussing this and actually we haven't found the real answer yet At the moment we say Cloud management system owns the state So the amount of which hypervisors are connected to a particular network, which virtual machines are running on a particular network
20:21
That's all state that is in the Cloud management system So if there's any kind of disruption in communication between OpenDaylight and any Cloud management system or stuff That's where we're actually going to look So we're going to look towards the Cloud management system and say okay, let's push new data sync the data into OpenDaylight
20:45
That's not too fast And there's actually some timing issues OpenDaylight was slated to have a release on December 9 The first hydrogen release We slipped a bit with the release date So we're now actually closing on the release date
21:00
So we had a lot of great ideas in OpenDaylight where we wanted to go We wanted to create an OVSDB plugin that would really allow you to manipulate any kind of OVSDB type of system implementing the JSON-RPC protocol to manage OVSDB And we wanted to have another plugin that actually does all the heavy lifting
21:20
of working with OpenVSwitch and actually making it into a system that allows you to plug multiple types of OVSDB using modules in there We just couldn't get it done with the time available and with the people available So we ended up with a sort of hybrid solution where we have an almost generic OVSDB
21:41
integration which implements the JSON-RPC protocol as defined in the request for comments But it's also mixed with a lot of higher level codes where we make decisions which are particular for OpenVSwitch Like we know that OpenVSwitch If I create a bridge, I need to create the bridge and I need to add it to the OpenVSwitch database
22:01
That's something that's really specific for OpenVSwitch At the moment it's still in the generic OVSDB code Because at the time it was the best solution to actually get something working for the hydrogen release Might not be the best or the most ideal solution But for now it's the way we actually made progress and we actually have some working stuff out there
22:21
in the release So again a lot of discussions going on in the weekly meetings It's about what actually is, what do we want to do and what's feasible to actually do in a project But in the end we got things done So I'm just focusing on the cloud stack side here But actually we got OVSDB
22:42
We got the module done We got it into a release state We managed to get a really stable API out there There's a Neutron integration for OVSDB and there's a cloud stack plug-in And the cloud stack plug-in is now pushed into the ACS master branch So it's slated for the next release Not going to be in the 4.3 release
23:01
But hopefully it's going to make the 4.4 release Depends a bit on where we go with both the open daylight project and the cloud stack project But for now we're hoping that we have a stable controller platform in open daylight So we can push a stable plug-in with cloud stack for the next development iteration
23:21
So let's get a bit into detail about what we built So And the setup, like I explained in the beginning of my talk, the purpose was to have a couple of KVM hypervisors and be able to build an overlay network between them So my test setup consists of two KVM hypervisors open p-switch installed on them, a cloud stack
23:42
management server and an open daylight controller This is actually a pretty easy setup You can set up in VirtualBox on your own machine There's some pre-setup that you need to do We couldn't get everything in time into the OBSDB plug-in So there's a couple of configuration issues you need to do if anybody wants to repeat the tests
24:02
Just shoot me an email or contact me on RACM We'll get you sorted Everything else is actually done by software So in cloud stack we built a plug-in and as part of the plug-in we created the UI and part of the UI is actually adding
24:20
the controller And here we try to keep stuff as simple as possible So by adding a controller to a network or adding a controller to a physical network in cloud stack it means that you have a construct where you can send commands which you can enable for individual networks So here's just a simple screenshot For those of you who want to know those question marks are about me not really understanding
24:41
the internationalization in cloud stack It should be fixed somewhere But the main point here is that we can now attach an open daylight controller to a cloud stack physical network And for cloud stack this particularly means that we have the ability to configure it
25:02
to use it and to make it part of any user's network If we want to make it part of the network for a particular user we use a model that's called the offering model in cloud stack So in cloud stack if I want to
25:20
give something, make a resource available to a user I create an offering An offering consists of several settings, for example if you have a compute offering it can be a number of CPUs a couple of megahertz or a amount of memory and in this case we're focusing on the networking offerings I'm actually going to tell the end user this is where you need
25:42
which services are going to be available on the network, which functions do you want on the network and which providers do you want to use for those particular functions So as you can see here, for example port forwarding uses the virtual router provider which is basically the network function virtualization construct that actually provides low-balancing
26:00
firewalling, etc. And for the virtual networking we're using the open daylight plugin Virtual networking is the name we've used to select which software-defined networking vendor is actually going to be used to provide this particular network service So with this offering we can actually allow the user to create a network
26:21
So up at this point it's all admin work and from here on it's actually up to the user to actually do stuff So this is what the user actually does So the first thing the user usually does is he creates a network In Cloudstack there's a
26:40
if you use a UI you create a network and once you create a network you can actually create an instance into the network So this is part of the open daylight UI and the code inside the plugin that we've written works in the following setup You create a network
27:00
in Cloudstack, nothing happens yet You create your first virtual machine in Cloudstack and the network switches from state allocated to state implemented During the implementation phase of this network it will actually start to create a couple of things So the first hurdle we had to solve here is how to get the configuration that we know about the hypervisors into the open daylight controller
27:22
There were two trains of thought here First of all, if we connect the open daylight we can immediately push our entire cluster setup to open daylight and make sure it's all pre-configured We went this route at the first iteration of the plugin, but actually decided not to pursue this The problem here is that if you make changes
27:41
to your cluster setup later on you need to have some kind of synchronization between open daylight and Cloudstack to say, okay, I'm adding a host to my cluster and now I'm suddenly going to have to add it to open daylight as well We decided for this first version to go for a really easy way of doing it Just when you boot a virtual machine it knows where the virtual machine is going to be
28:00
provisioned, and when the virtual machine is provisioned it knows that to push that particular configuration to the hypervisor So when the first virtual machine is actually provisioned, it sends a call to open daylight saying, okay, I've got a new hypervisor can you connect it? And this is a call to the Connection Manager API in open daylight Connection Manager API will actually
28:22
create a new node in open daylight of type OpenVSwitch and will connect the OVSDB plugin Part of connecting the OVSDB plugin is an auto-discovery process that will discover all the existing switches on the OVSDB and actually create two specific switches One of the switches it creates is the BR-INT which is, we call it the integration bridge
28:42
This switch is configured to use normal switching capabilities and have VLANs So any machine you connect to it in a particular VLAN will be available to all the other machines on the same switch, in the same VLAN just like you would in a regular sense And the other one is the BR-TON And the BR-TON interface is a flow-controlled switch
29:02
meaning that without actually pushing any flows, nothing will happen on that switch and this is the one we're going to use later on to actually drive traffic using the overlay network to the other hypervisors in the network When this switch is actually provisioned and the open daylight reports that it now knows about this particular hypervisor
29:20
we send it a network and first this was actually interesting because here we're using the Neutron API So Neutron has a concept about networks and ports and we reused that particular idea to push our own data into the system So we push the network, we give it a unique identifier which is the same as the unique identifier used for the network in CloudStack
29:41
and we push a port and a port here is like a virtual network interface So at this point there's only a single machine running on the hypervisor but we already know about the hypervisor and we know that Open Daylight suddenly knows that there's a network with a certain UUID and there's at least one machine configured to use this network
30:01
with a certain UUID The second step is when you boot the next virtual machine and now I'm going to assume that you use a system that allows you to make sure that this virtual machine boots on the second hypervisor, otherwise it would be a very boring talk
30:21
So we're going to go through the same motions again So we start the virtual machine CloudStack will try to look up the hypervisor, sees that it doesn't know about the hypervisor yet by sending a call to the connection manager saying, hey, do you know about this particular IP address? No, I don't know about this particular IP address So it sends another connect call to the hypervisor
30:42
At that point it will run through the same procedure set up the brint, set up the brton and basically return back to CloudStack, okay, it's done Well, we already know about the network that's something we can actually check So the interesting magic happens when we actually start the port By starting the port on the second hypervisor
31:01
We're actually sending a signal to OpenDaylight like, okay, I've got a machine living on hypervisor number one and I've now got a machine running on hypervisor number two OpenDaylight recognizes that those two ports belong to the same network If they belong to the same network it means that we need some kind of configuration between the two
31:21
It checks if there's actually a tunnel interface between the two, so this is really the magic of overlay networking When it sees that there needs to be communication between the two hypervisors, it wants to create a tunnel In this case we're using GRE tunnels but we can just easily switch them to VXLAN tunnels or any kind of tunneling system
31:40
currently supported by OpenVSwitch And then we need to start provisioning flows And the flows is really telling the system what to do So on the brint we're using the regular switching flows using VLANs to separate the individual networks, so every network in Neutron has a built-in VLAN in the OpenVSwitch
32:02
that we use to communicate between the brint and with the patchport that's going to the brton And on the brton we're going to use flows The front part here since we already have all the information in the port, so we know exactly what MAC address is used, we know which IP address is used, we can make really detailed flows what we want to happen
32:22
So we're not using any controller magic yet, but we're really pushing static flows like, okay, I know if I get a packet from this particular MAC address, and its destination is this other particular MAC address or it's going to be in this network, I'm going to push it to this particular tunnel. Every tunnel has a separation idea, so we know that a tunnel belongs
32:42
to a certain network So by pushing this flow on the tunnels, or all the tunnels the moment you have more hypervisors we know that the traffic is isolated and only belongs to a certain network And it's also a built-in security, because it's automatically anti-spoofing, you can't just push any MAC address on a network and expect it to be delivered
33:02
to the other end of the network It will actually only work if you have the correct MAC address But since we are a cloud management system we know the MAC addresses of all the machines we make we have a built-in security some kind of port isolation and we try to limit the traffic over the various tunnels to not completely saturate the tunnels
33:20
as the traffic has to go to another another space or another hypervisor And Open Daylight performs all this completely, automatically There's nothing I need to do from Apache Cloud Stack to actually make this happen All the flows get pushed There's going to be a couple of special flows pushed to allow the traffic to go out into the tunnel and actually, when
33:43
flows exit the tunnel on the other end we will see, okay, this is part of tunnel number A tunnel number A is part of network vlan100 So we're actually going to distribute this particular packet send it back to the BRN to access vlan100 and with vlan100 it will be sent to the individual virtual machines on each side
34:02
And then you have the moment everybody was waiting for We have Bing established a network connection So is this going to be it?
34:20
No Like I said in the beginning of my talk Open Daylight is really a project that supports a lot It supports OpenDAV We don't do that yet It supports virtual tenant network We don't do it yet It supports something that I haven't thought of that's going to be in there tomorrow and we don't support it yet So this is very much a work in progress I'm happy
34:41
I'm allowed to show it here to tell people a little bit about the Overlay Networking but there's so much more that can be done So it's really just the first step in the whole process of getting support for Open Daylight A lot of people were mentioning already Apache Cloud Stack supports Open Daylight What we do, but it's only really a first step There's so much more to do and I really hope we can continue working on this
35:04
Next to having a technical advantage of being able to leverage two different projects We've actually seen a lot of community advantages to actually working with two projects Because we are now talking There's people from Apache Cloud Stack talking to people from Open Daylight
35:21
People from Open Daylight talking to Apache Cloud Stack And actually in all the discussions we had in the channel and all the other environments where we met up We're actually talking with a lot of Open Stack people as well So we're trying to really coordinate and get a lot of ideas going If you put more than a couple of geeks in the room you get a couple of great ideas So even here in Fosdam this year
35:43
by talking to people you get more ideas about networking more ideas about how to share ideas So this plugin for Apache Cloud Stack it was co-developed by people working on Open Stack They didn't write any code but they contributed ideas and they gave feedback about how to work And the same went the other way around By being there in the channel
36:01
having discussions about what this project to do and where to be going We helped each other For me this was really a nice example about open collaboration and really the power of working in an open source community So that actually brings me to the last point If you have any bright ideas about where this should be going
36:21
Feel free to ask or make any comments So that's it A little bit faster than I initially expected So hopefully a lot of time to answer any of your questions
36:46
So any questions? Okay, thanks a lot