You have already seen how networks can be built with the OpenStack
GUI, how they can be connected to routers, and eventually to the outside world.
In this section, you will use the commandline to achieve similar
results and learn a bit more about OpenStack's networking concepts.
Before we talk about Neutron though, you need to know that the Newton
release still supports the older network management service, Nova Network.
Then to understand the purpose of the various Neutron concepts,
we will review how networks are used in a data center.
And after this, we will look at how Neutron models the various aspects of networking.
You will then finally get a glimpse on how a server's network
connection is made, and how you can control the IP addressing.
Throughout this presentation, you will also see how the abstract
concepts are put into practice.
Remember that the original OpenStack was created by NASA and Rackspace.
NASA's server management was baptized Nova.
In the beginnings, Nova managed everything, not only servers,
but also images, access control, networking, and storage.
One after the other, new separate services were spun out of Nova to
handle these aspects of a cloud. With the Grizzly release of
OpenStack, Quantum was added as a separate networking service.
Due to trademark considerations, it was soon re-baptized Neutron.
By today, Neutron is the standard network management service,
but Nova Network is still supported, since some important OpenStack
installations don't use Neutron.
At the beginning of the Nova module, we discussed what is required to
manage and use physical servers. Let's do the same for networks.
This is the three-tier application you saw already in the first course module.
The application runs on web servers, business-logic servers,
and database servers, and each server group has its own network.
Networks are connected by routers, and the whole setup is fronted by load balancers.
There needs to be at least one IP address that is accessible from the outside world.
A single external address shared by the load balancers might be
sufficient, but depending on the architecture, you may need more.
You probably share the cloud and the underlying network infrastructure
with other customers or projects, but you expect your networks to be
isolated from each other, and particularly from the networks of other
people, so that they can't see your traffic.
In a data center, a solution for this problem has traditionally been VLAN technology.
You will learn in the second part of this course that Neutron can also
use VLANs to isolate networks, but other technologies are available as well.
You know already that OpenStack surrounds servers with firewalls,
which can be configured with security groups.
This is a networking concepts, and security groups are actually not
managed by Nova, but Neutron. Servers need IP addresses to talk to each other.
Usually, they don't have static IP addresses, but obtain them from DHCP servers.
By default, each network has a DHCP server.
In this presentation, we will see how a user can use these concepts,
except for the load balancers.
To implement Nova's abstract servers or instances, about 10 different
virtual machine technologies are supported, plus physical machines.
The networking landscape is far more complex than the hypervisor market.
Many networking technologies exist, and a data center usually employs
several technologies to implement its networking.
The resulting picture is much more complex than for instances.
For example, you may have servers in racks connected together with
top-of-rack switches. Racks are then connected with other switches or perhaps routers.
The cables shown here may actually be VLANs.
On the servers, you may use Linux bridges to attach your virtual
machines to the network, but other technologies exist such as Open vSwitch.
Or your cloud may use software-defined networking.
Many SDN controllers exist, let's just mention OpenDaylight as an example.
Finally, your cloud might span several data centers, and racks are
connected via a networking cloud that might have its own complex implementation.
Neutron tries to accommodate as many such implementation options and
their combinations as possible. This is done through a plugin
framework, which makes it possible for developers to add new network
implementations to Neutron. Like Nova, Neutron shields the user from
the implementation complexities and offers a single
comparatively-simple user interface based on a few core concepts,
no matter which technologies are used under the hood.
Like all other OpenStack interfaces, this interface is also RESTful.