Bring your virtualized networking stack to the next level
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 |
| |
| Subtitle |
| |
| 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/32494 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2014117 / 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
Software developerSoftwareSoftware maintenanceLevel (video gaming)Multiplication signOpen setStack (abstract data type)Projective planeNumberProduct (business)AreaPole (complex analysis)Online helpXMLLecture/Conference
00:51
Exterior algebraConfiguration spaceSoftwareOpen sourceRight angleProjective planeSphereCore dumpComputer animationLecture/Conference
01:18
LogicSoftwareVirtual LANCategory of beingIP addressHuman migrationService (economics)Data storage deviceSingle-precision floating-point formatRepresentational state transferOpen sourceData centerKey (cryptography)Router (computing)Game controllerParameter (computer programming)Domain nameBroadcasting (networking)Different (Kate Ryan album)Computer configurationConfiguration spaceInterface (computing)Overlay-NetzReal numberDrop (liquid)Point (geometry)Order (biology)Information securityDrag (physics)Bridging (networking)VirtualizationPlug-in (computing)Moving averageComponent-based software engineering1 (number)Computer architectureProjective planeControl flowConnected spaceQuicksortGreatest elementExtension (kinesiology)MathematicsNetzwerkverwaltungGroup actionAtomic numberLevel (video gaming)Game theoryLatent heatStaff (military)State of matterAddress spaceINTEGRALSet (mathematics)Hand fanComputer clusterForm (programming)Natural numberVector spaceNormal (geometry)VarianceComputer virusClient (computing)ImplementationComputer networkFunction (mathematics)Video gameElectric generatorEvent horizonDemosceneBlock (periodic table)TouchscreenDegree (graph theory)Computer animation
10:51
SoftwareRegular graphTheoryInternet service providerLogicInstance (computer science)Information securityIP addressArithmetic meanDifferent (Kate Ryan album)Level (video gaming)Scaling (geometry)Power (physics)Overlay-NetzLatin squareCASE <Informatik>MereologyBitTouchscreenDataflowAuthenticationVirtual machineGame controllerConfiguration spaceRight angleMetropolitan area networkState of matterDomain nameNP-hardPerspective (visual)Group actionConnected spaceLine (geometry)Order (biology)Special unitary groupDiscrete groupNetzwerkverwaltungSummierbarkeit1 (number)Product (business)Field (computer science)Address spaceType theoryBoss CorporationImplementationForestNetwork topologyDigital rights managementRow (database)Rule of inferenceQuicksortData storage deviceINTEGRALDefault (computer science)RoutingPlug-in (computing)VirtualizationRange (statistics)Selectivity (electronic)Firewall (computing)Virtual LANComputer hardwareService (economics)MultilaterationQubitInterface (computing)Decision theoryMultiplicationComputer animation
20:23
INTEGRALSoftwareInformation securityRule of inferenceAuthenticationGroup actionRight angleState of matterTouchscreenOrder (biology)Electronic mailing listConfiguration spaceLevel (video gaming)Forcing (mathematics)Router (computing)Server (computing)Scheduling (computing)TelecommunicationDirect numerical simulationGradientService (economics)Internet service providerImplementationPublic key certificateVirtualizationGateway (telecommunications)Firewall (computing)Open sourceFunctional (mathematics)EncryptionEmailRoutingGodOpen setPerspective (visual)Process (computing)Bridging (networking)Event horizonGame controllerWeb pageComputer configurationPlastikkarteLatent heatInformationPlanningPrice indexBitQuicksortSpring (hydrology)Interface (computing)Graphical user interfacePlug-in (computing)Set (mathematics)Connected spaceField (computer science)QubitOcean currentIntrusion detection systemLebesgue integrationInstallation artWikiSoftware bugComputer animation
29:56
Internet service providerSoftwareHuman migrationElectronic mailing listNetbookExtension (kinesiology)Group actionState of matterRegular graphEmailRepresentational state transferBand matrixLevel (video gaming)Multiplication signLecture/Conference
Transcript: English(auto-generated)
00:01
OK. Hi there. I'm Mike. I'm from Reddit, software developer at Reddit. Also, maintainer on the OVID project. So who here has heard about OVID or been to one of the talks? OK, so some of you. And who hasn't been a tough luck, because I'm going to be talking about the networking
00:21
OVID. So no OVID introduction this time. But hopefully, you will understand. If not, you can check out the OVID.org, learn about OVID. So basically, I'm talking about how to bring your virtualized networking stack to the next level using OVID and Neutron. So if you know Neutron, show your hand.
00:42
Open stack Neutron. Cool. OK. So basically, let's see what we're going to talk about. OVID network configuration. So how do we configure networks today in the OVID project? OVID is like an open source alternative to vSphere, vCenter.
01:03
Then we go over Neutron, see what it has to offer, what are we looking to do with it, and some future work that we have planned. So OVID network configuration. Basically, in OVID, we have this entity called the network.
01:20
It represents the logical entity, represents layer 2 broadcast domain. And it's defined within the scope of a single data center. So you can have multiple data centers, each with its own networks. And these networks, when you want to put VMs on them, they have this green drawing.
01:43
It says it's a VM network. And behind the scenes, the VM network is implemented using Linux bridge. So that's an in-house solution with OVID. The Linux bridge for VM networking. And for segregation, we use VLANs.
02:01
So if you've been to a soft stock, you already know what are VLANs. And if not, hopefully, you know what are VLANs. It's very simple implementation. So to add the new network in OVID, in the previous interface, you have a new button.
02:20
You press the new button, and then you get this dialog. Basically, you have to fill the name of the network. So just call it whatever you want. And you have to fill out some networking parameters. Like if you want to use a VLAN to segregate the network traffic, you put the VLAN tag. If you want to use it for VMs, then you can specify a specific MTU and some other properties
02:43
that I'm not going to cover now. And now that we have this network, it's great. It's logical entity. But it doesn't actually do anything yet. And we need to apply it on the host. So in OVID, network definition is done statically on each host.
03:01
And we have a hosts tab with a subtab of the network interfaces. I have this nice button called setup networks, which opens this lovely dialog with drag and drop capabilities. So on the left side, the leftmost side, we have the actual interfaces of the host. And we can decide to bond interfaces or break bonds.
03:23
So you can create bonds directly from the UI. And on the right-hand side, you have the logical networks that you need to put on the host. So the required ones are those that have to be on the host for it to be able to run the VMs in that cluster.
03:42
And non-required are just the non-required networks. If you have it on the host, great. If not, then you don't have to put it on. And in the middle, you just see where these networks are dragged so which network you can attach to a specific networking interface. And also in the bottom, I don't know if you can read it,
04:02
but it says check connectivity between host and engine. So basically, if you lost your connectivity and this was checked, then the host will roll back its network configuration back to working state. So you don't actually lose connectivity to the host.
04:21
And also save network configuration is an option that you can use just to play with the networking, like set up different networks and experiment with it. And then you can, again, roll back, but not like losing connectivity, roll back. Just roll back the changes. So now that we applied all the networks,
04:42
we went over all the hosts and set up the networks. We need to actually use them inside the VM. So on the new VM screen, we have this option in the bottom to add NICs. So each NIC, we just choose which network we want. And we can have multiple NICs.
05:01
That's during the VM creation. We can also add networks later when the VM is already running or in stop state, whatever. And that's it, basically. So what are we looking to gain from the integration? So this was very simple, not really complicated stuff.
05:22
It's like basic networking, just layer 2 networking. And it's only Linux Bridge and VLAN. So we want to have support for more technologies, like Cisco routers and stuff like that, which we can't normally have, or open vSwitch,
05:43
because we're using just Linux Bridge and VLANs. So basically, Neutron has all these. We want to use it. And also, the layer 3 services, so OVID really doesn't have any layer 3 capability in this regard. I want to have IP addresses for the VMs and stuff
06:02
like that. And we want to enjoy both worlds, because OVID is really powerful at managing the, let's say, infrastructure networks, like storage and migration network, and all these networks that the VMs don't necessarily have to use, but they just use for migration traffic
06:23
and throttling your network, separating it. So as you have seen, it's really easy in order to do the network configuration for that. And for the VMs, Neutron is way more powerful. It has more capabilities. So we would like to use Neutron for managing the VM networking
06:41
aspect. And because we want to integrate it into OVID, the VM networks will be as any VM network in OVID. It will still have permission capabilities and all sorts of VM-level capabilities that exist in OVID. It will also apply to Neutron networks.
07:03
So basically, it's like having the best of both worlds. OVID for managing the infrastructure, and Neutron for having the VM connectivity and segregation and so on. So let's see what is Neutron. What is this Neutron I'm talking about? So basically, it's an OpenStack project.
07:21
It's like the networking component of OpenStack, but it's actually a standalone component that we can install and use in any projects such as OVID. So it basically provides network connectivity as a service. So I, as a user, can go to Neutron and ask him, hey, Neutron, give me a new network
07:40
that I can use for my VMs. And Neutron takes care of all the gross details for me. So it configures a villain or other segregation technology. And I don't mind. I don't see it at all. I just know my traffic is safe. And all the VMs on the same network can talk to each other.
08:02
So that's one point. And it also has a wide support for plugins. It has a plugin architecture that each vendor or just networking technology can implement. So there's lots of plugins. Linux Bridge, OVS, ML2 is the new one.
08:22
And Cisco, NYU, Cisco, NYU, other lots and lots of plugins. Some are open source. Some are closed source. And basically, that gives us a lot of flexibility. And it is accessible via REST API. So all the work we do is integrating with REST API.
08:47
So this is the top-level architecture of Neutron. There's the clients, the API clients, and the Neutron API, which is REST API for us. So basically, there's the basic API. And there's also extensions which
09:00
are not mandatory for a plugin to implement. And there's the plugin itself. It implements the base API and whatever extension it chooses to implement. So that's the Neutron service. And on the compute node, on the hypervisor and the host that is running the VMs, it is either
09:22
configured by an agent that is running locally on the node or by some controller, let's say, UCSM or maybe SDN controller that also knows how to configure networking on that host. So what are the key features that we are looking
09:41
to integrate into OVID? And basically, the most interesting stuff in Neutron at all. So we have the better network virtualization using overlay. So if you have been to Asaf's talk, he explained about it. I will go over it briefly. Also, IP address management, like ability to give IP addresses to the VMs, security groups,
10:05
and lots and lots of as a service stuff, like everything as a service. And virtual routing, which is also router as a service. So first thing we wanted is to have this better networking
10:21
using overlay networks. So what are overlay networks, and why do we need them? As I said, OVID uses VLANs. VLANs is the naive way to virtualize your networking, and it works up to a point. You can segregate the traffic, but it's very limited. It's a 10-bit field, so you have approximately 4,000 VLANs.
10:45
And in real life, in real scenarios, you wouldn't have more than a couple of hundreds, because otherwise, it just doesn't scale. The switches, they can't hold all the more expensive switches can handle it, but typical switches
11:03
don't hold more than a couple hundred VLANs. And it's also hard to maintain. If you have a switch, and you want to set up a networking topology, and you want to set up a new VLAN, you have to go to all the switches in that network
11:23
and allow the VLAN to pass through. You have to mark it as a trunk. And it also has no brains. VLAN traffic is not directable. It's just whatever the switch decides. So if it knows how to route it, it will route it to the right destination. If it doesn't, then it will flood,
11:41
or I don't know, whatever layer 2 logic is in there. So overlay networks come to alleviate these issues. So basically, it's mostly unlimited, like 2 million theoretical networks. And because it's not a layer 2 technology, it's layer 3 and above, it's actually not something
12:01
that the switch knows about necessarily. So regular hardware can work with overlay networks, no problem. And they're easy to maintain, because as I said, it's not a layer 2 technology. It's not VLANs. You don't have to configure anything on the switches. The most crazy thing you might do
12:21
is open firewall for that or something, but that's it. And it also can be smart. If you're using SDN, SDN controller, it will direct the traffic and make it flow in the best possible flow for the network. So basically, overlay networks looks, on the paper,
12:42
it's a lot better. But of course, it depends on the use case. VLANs are still a bit more high performance in some cases, because there's stuff like hardware offloading. So hardware basically supports VLANs, and it doesn't support, yet doesn't support
13:02
overlay networks. So if you need small scale, VLANs probably is good for you. If you need the large scale of networking, lots and lots of different users with different networks, you would use overlay networks. And basically, this is available since OVID 3.3, when we integrated Neutron.
13:21
So OVID is just using Neutron. It's just asking it for a network. It doesn't care which one of the technologies it uses. So it's completely transparent to it. What else? IP address management, we wanted to be able to deliver IP addresses to the VMs.
13:43
So fairly simple. Neutron has three main entities, the network, the subnet, and the port. So a network is just like in OVID, some sort of virtual layer 2 network. And subnet is one or more subnets can be attached to a certain network, just subnet IP3,
14:03
like layer 3, IPV6, or V4 subnet. And the port can have IP on one subnet or more of that network. So port is just a connection to a network, and you can define IP on it. And this IP gets delivered in the end by a DHCP service
14:23
that Neutron is running. So basically, this was also available from the first integration. But you couldn't define the subnets. You would just define networks in OVID. And you would have to define the subnets in Neutron itself. And now we added this capability in 3.4
14:42
that you can also define these subnets. We will see later an example. And last of all, security groups. So what are security groups? It's just a way to segregate your VMs from the outside world. So by default, the VM will get no traffic coming into it,
15:03
just return traffic if it initiated a session. And all outbound traffic is allowed. But you can control it. You can have in the security group, like in each group, there's multiple rules. So you can define, like, I only want people to be able to SSH to the VM, and I don't know.
15:22
I want to block outgoing traffic for this port range or whatever rules you can think of. And each port can have one or more security groups attached to it. So basically, this is kind of new in OVID 3.4, because before that, it just didn't
15:42
know about the security groups, and it didn't care. So it might or might not work. And in 3.4, you just can specify which security groups you want to use. And if the default is used, it will also support it quite well. So let's see how we integrated the two projects.
16:02
So from OVID perspective, Neutron and some other external providers, just a new concept, external provider. It's a software that is running externally to OVID and can provide the resources. So basically, we can have external provider
16:20
that can provide networking and external provider that can provide hosts, and external provider for storage. So basically, Neutron is one of those external providers that we defined. And you can deploy it with whatever plug-in you want. You just set it up by yourself.
16:44
And it can be used in any one of the flavors. Like, you always set it up once, and then you don't have to really touch it again. But you can use it the OVID-centric way. You create networks in OVID and tell it to create them using Neutron.
17:01
So it's just some sort of implementation detail that you don't really care about. Or you can go the Neutron-centric way, where you just import the networks from Neutron, and you manage every aspect of the networking inside Neutron. So OVID supports both flavors. Of course, you can mix and match.
17:20
You can have some networks managed solely through OVID, and some managed from the Neutron side. So how to use Neutron in OVID? It's pretty simple, just a few simple steps. So first of all, you need to install a Neutron instance. And after that, you add the instance
17:42
as an external provider, add the networks on the provider in one of the two flavors, install the hosts, and use the networks in the VMs. So let's go into detail into each one of the steps. So basically, installing Neutron, that's what you have to do by yourself.
18:00
You go, you install Neutron on some machine. It can be the OVID machine or some other machine. And just choose whatever plugin you want. And if you want security authentication, then you need to install Keystone and also configure Keystone to talk with Neutron. So that's the hardest part of this integration.
18:23
All of the other steps are in OVID. So first, you add the Neutron provider. So you fill out the fields like name, select the type. So it's OpenStack networking. Select a plugin, or you can enter your own plugin if you are using some other plugin, other than Linux,
18:42
Bridge, or OVS, which are currently the ones predefined. Enter the URL. And if you need to specify the authentication details, then you just enter require authentication and fill out the details. Are you specifying more than one plugin?
19:01
No, currently it's only one plugin per provider. But you can have multiple external providers. So it's just a new provider per each plugin type, if you want. It's not perfect, the integration, right? It's evolving. And if you choose a plugin that requires agent,
19:21
then we have the agent configuration screen. So basically, interface mappings is just a template. And the qubit details for the bus, it's just what's sent when we install the agent later. So we will see this actually later. And then once we have the external provider, then we add the network.
19:41
So basically, pretty similar to the add network screen before. Just an important part is to check this create on external provider checkbox and select which external provider we want to use. So if you have several networking providers, we can create it on either one of them.
20:01
And also, in this screen, we can specify the subnet that we want. So if you want to create a subnet immediately, we can just specify the subnet details and it gets created for us during the network creation step. Or I can do it also after the network has been added. Or the other way, it's the neutron centric way.
20:23
We have an import button, and we just see all the networks on some provider, and we can choose to import them into OVID. So that's either of the flavors. Either you add the network by yourself, and neutron is just an implementation detail, or you edit a neutron and import it into OVID.
20:43
So now that we have the networks all set up in OVID, it's still logical networks. We still need someone to do the network configuration. So as we said, it's either an agent or some controller controlling the host. So if we have an agent, when we add a new host, we have this external network provider tab,
21:06
and we can choose which provider we want to create the agent for, like install the agent. And also we need to specify the bridge mappings, which is some neutron configuration that tells it which interfaces to use for the networking.
21:21
So that basically installs the host, installs with DSM, and also creates the agent on it, configures the agent. We see also we have the qubit fields that we filled up earlier. So all the configuration, all the needed configuration is sent, and we're set to go. And then we just need to add the network to a VM.
21:43
So basically here we can see that we can also add the NIC to a VM, not necessarily in the new VM screen. So it's either in the screen that we seen earlier or this screen. You can select the network that you want to use for the new virtual interface card.
22:01
And it's just like any other network. You don't have any specifications saying that this is external network. I just called it like that. But basically it's because this network for the VM perspective, it doesn't matter. It's if Ovid is controlling the network or Neutron,
22:22
the VM doesn't care, it just uses the network. And basically in the end you run the VM, cross your fingers, and everything works, right? Especially if Neutron is working. So yeah, he's asking if you can specify
22:48
stateless firewall rules on the subnet level. So basically if you can do it in Neutron, you can probably do it in this integration because we're supporting almost everything Neutron does,
23:00
like from what you've seen. But if it has stateless rules, then it probably would work, right? But I don't know if they support stateless rules. I know security groups and security groups is stateful. Any other questions up until now?
23:20
Yes, please. The question is if the connection between Ovid and the Neutron provider is encrypted or in plain text. So basically Neutron provider doesn't support encryption.
23:44
It's meant to be connected to locally or something, I don't know. And if they support encryption, we will also use encryption, of course. We have Foreman provider for hosts, so that does support encryption, and we actually do the certificate exchange
24:01
with the Foreman provider, right? But here they don't support it, they don't support HTTPS, so it's basically plain text. But they do have the Keystone authentication, that's what they say. I don't know, you will have to ask OpenStack guys, why don't you support HTTPS, right, SSL?
24:23
Yes, please. So the question is if we are able to see the virtual interfaces on the OpenV switch.
24:40
So basically you don't see the virtual interfaces on which host are they run, you see them on the VM level. So it's not really, you wouldn't be able to list in Ovid which NICs are what on the host right now. But it might be a good idea, you can open an RFE for that, right?
25:42
So what is the question exactly? So question is, is the DHCP server supporting extra options like gateway, and routes and stuff? So yeah, basically Neutron is supposedly supporting this, so you can define gateway, routing, DNS servers,
26:05
to be sent from the DHCP. Currently we didn't integrate it, it's on the list of things to do. But the DHCP service is like an agent running in Neutron, you have to set it up annually by yourself, and if it supports that or not,
26:22
it depends on Neutron, right? It's like if they have a bug. Yeah, theoretically it supports all the extra options via DHCP. Yeah, we're working on adding GUI for all these options.
26:42
So basically, future work that we have planned. So of course if something is not mentioned, you're welcome to open a bug or RFE on Ovid. So first of all, we want to integrate more advanced services like all the VPN as a service,
27:01
disaster recovery, whatever, all these extra services that Neutron provides. We also want to improve the VM scheduling, because currently when we start a VM, we don't know which host is going to provide which network. So it is possible that some host
27:22
maybe is not capable of providing a network, so we would want to know that and actually not start the VM on that host. And also monitor the VNIC connectivity, because even if the VM is starting and supposedly it is connected to the network, maybe it doesn't have any traffic flowing through it.
27:42
So we want to be able to know that, tell the user like, hey, something is wrong here, or give some sort of indication. Also, we want to integrate security groups more tightly, because currently it's just, if you want to use security groups, you can, but you just specify what security groups' IDs
28:02
you want to use, and that's it. I want to be able to create security groups, like we can create subnets currently from within OVID, want to give this control to the user, and also integrate layer three functionality, like virtual routers, floating IPs, have all that working from OVID.
28:22
And of course, support more plugin types, like Cisco, RIO, NEC, all that stuff. So we went over, in conclusion, we went over OVID network configuration, how it works, went over the Neutron bit,
28:40
and so what we stand to gain from it, what's currently happening, and we also saw some planned future work. If you want more info, you can check out these links. So Neutron basically does the wiki for Neutron. In OVID, we have a very detailed page about the integration and what's currently happening, what is planned next.
29:01
You can find us also on the mailing list and on the IRC channel. And that's it. Do you have any additional questions?
29:22
The question is, does Neutron support failover IPs? So basically, if you live migrate, I'm not sure if the IP supported, like failover IP. But yeah, I'm not sure if it supported.
29:55
I don't know, I haven't tested it with live migration, so probably like a to-do item.
30:02
But basically, if it doesn't support it, then it's Neutron's fault, not OVID's. So question is, do we expose API calls to get the bandwidth consumption on the network?
30:23
So currently, I don't even think we have it on regular OVID networks. And Neutron is still in the tech previous stage. It's not quite cooked yet, so there's no official REST API support for it. So basically, when there will be, and if we would have bandwidth for regular networks,
30:43
then we'll surely try to have it on Neutron networks. But that kinda depends what Neutron provide us. Sorry, I didn't hear that. The X, I'm not sure, what is the question?
31:07
The routing extension API? So question is, do we support the routing extension API? So basically, it should work, but I'm not sure. We haven't tried it yet. Like, we didn't integrate the routing stuff
31:22
that's on the to-do list. If you want external network with external connectivity, you can create it from Neutron and consume it, like import it into OVID.
31:40
But you can't still create it from OVID directly like that. So thank you, I think we're out of time. But if you want to ask questions, you are welcome to either catch me right now or ask on the mailing list. Thank you very much.