neutron

Bug #1458890
Comment #0

Comment 0 for bug 1458890

Revision history for this message

Kyle Mestery (mestery) wrote on 2015-05-26: Add segment support to Neutron

This is feedback from the Vancouver OpenStack Summit.

During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN, Rackspace, HP, BlueBox, among others) meeting, there was a discussion of network architectures that we use to deliver Openstack. As we talked it became clear that there are a number of challenges around networking.

In many cases, our data center networks are architected with a differientation between layer 2 and layer 3. Said another way, there are distinct network "segments" which are only available to a subset of compute hosts. These topolgies are typically necessary to manage network resource capacity (IP addresses, broadcast domain size, ARP tables, etc.) Network topologies like these are not possible to describe with Neutron constructs today.

The traditional solution to this is tunneling and overlay networks which makes all networks available everywhere in the data center. However, overlay networks represent a large increase in complexity that can be very difficult to troubleshoot. For this reason, many large deployers are not using overlay networks at all (or only for specific use cases like private tenant networks.)

Beacuse Neutron does not have constructs that accurately describe our network architectures, we'd like to see the notion of a network "segment" in Neutron. A "segment" could mean a L2 domain, IP block boundary, or other partition. Operators could use this new construct to build accurate models of network topology within Neutron, making it much more usable.

Example: The typical use case is L2 segments that are restrained to a single rack (or some subnet of compute hosts), but are still part of a larger L3 network. In this case, the overall Neutron network would describe the L3 network, and the network segments would be used to describe the L2 segments.

WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity. This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.

Example: The end user chooses the Neutron network for their instance, which is actually comprised of several lower level network segments within Neutron. Scheduling must be done such that the network segment chosen for the instance is available to the compute node on which the instance is placed. Additionally, the network segment that's chosen must have available IP capacity in order for the instance to be placed there.

Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.

This is feedback from the Vancouver OpenStack Summit.

During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN, Rackspace, HP, BlueBox, among others) meeting, there was a discussion of network architectures that we use to deliver Openstack.  As we talked it became clear that there are a number of challenges around networking.

In many cases, our data center networks are architected with a differientation between layer 2 and layer 3.  Said another way, there are distinct network "segments" which are only available to a subset of compute hosts.  These topolgies are typically necessary to manage network resource capacity (IP addresses, broadcast domain size, ARP tables, etc.)   Network topologies like these are not possible to describe with Neutron constructs today.

The traditional solution to this is tunneling and overlay networks which makes all networks available everywhere in the data center.  However, overlay networks represent a large increase in complexity that can be very difficult to troubleshoot.  For this reason, many large deployers are not using overlay networks at all (or only for specific use cases like private tenant networks.)

Beacuse Neutron does not have constructs that accurately describe our network architectures, we'd like to see the notion of a network "segment" in Neutron.  A "segment" could mean a L2 domain, IP block boundary, or other partition.  Operators could use this new construct to build accurate models of network topology within Neutron, making it much more usable.

Example:  The typical use case is L2 segments that are restrained to a single rack (or some subnet of compute hosts), but are still part of a larger L3 network.  In this case, the overall Neutron network would describe the L3 network, and the network segments would be used to describe the L2 segments.

WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity.  This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.

Example:  The end user chooses the Neutron network for their instance, which is actually comprised of several lower level network segments within Neutron.  Scheduling must be done such that the network segment chosen for the instance is available to the compute node on which the instance is placed.  Additionally, the network segment that's chosen must have available IP capacity in order for the instance to be placed there.

Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.