Difference between revisions of "NetworkService"
| Line 8: | Line 8: | ||
* '''Launchpad Nova blueprint''': [[NovaSpec]]:bexar-network-service | * '''Launchpad Nova blueprint''': [[NovaSpec]]:bexar-network-service | ||
* '''Created''': 31 January 2011 | * '''Created''': 31 January 2011 | ||
| − | * '''Last updated''': | + | * '''Last updated''': 1 February 2011 |
* '''Drafter''': [https://launchpad.net/~ewanmellor Ewan Mellor] | * '''Drafter''': [https://launchpad.net/~ewanmellor Ewan Mellor] | ||
* '''Contributors''': [https://launchpad.net/~patricka Patrick Ancillotti], [https://launchpad.net/~erik-carlin Erik Carlin], [https://launchpad.net/~dmd17 Dan Mihai Dumitriu], [https://launchpad.net/~dramesh Ram Durairaj], [https://launchpad.net/~soren Søren Hansen], [https://launchpad.net/~iida-koji Koji Iida], [https://launchpad.net/~ishii-hisaharu Hisaharu Ishii], [https://launchpad.net/~itoumsn Masanori Itoh], [https://launchpad.net/~adjohn Adam Johnson], [https://launchpad.net/~youcef-laribi Youcef Laribi], [https://launchpad.net/~romain-lenglet Romain Lenglet], [https://launchpad.net/~salvatore-orlando Salvatore Orlando], [https://launchpad.net/~john-purrier John Purrier], [https://launchpad.net/~termie Andy Smith], [https://launchpad.net/~troy-toman Troy Toman], [https://launchpad.net/~dan-nicira Dan Wendlandt], [https://launchpad.net/~zhixue-wu Zhixue Wu] | * '''Contributors''': [https://launchpad.net/~patricka Patrick Ancillotti], [https://launchpad.net/~erik-carlin Erik Carlin], [https://launchpad.net/~dmd17 Dan Mihai Dumitriu], [https://launchpad.net/~dramesh Ram Durairaj], [https://launchpad.net/~soren Søren Hansen], [https://launchpad.net/~iida-koji Koji Iida], [https://launchpad.net/~ishii-hisaharu Hisaharu Ishii], [https://launchpad.net/~itoumsn Masanori Itoh], [https://launchpad.net/~adjohn Adam Johnson], [https://launchpad.net/~youcef-laribi Youcef Laribi], [https://launchpad.net/~romain-lenglet Romain Lenglet], [https://launchpad.net/~salvatore-orlando Salvatore Orlando], [https://launchpad.net/~john-purrier John Purrier], [https://launchpad.net/~termie Andy Smith], [https://launchpad.net/~troy-toman Troy Toman], [https://launchpad.net/~dan-nicira Dan Wendlandt], [https://launchpad.net/~zhixue-wu Zhixue Wu] | ||
| − | == | + | == Goals == |
| + | |||
| + | Add a first-class, customer-facing service for the management of network infrastructure within an OpenStack cloud. | ||
| + | |||
| + | Allow the customer to configure rich network topologies within the cloud. These topologies will include private connections between VMs, and connections between VMs and network services such as load-balancers, firewalls, and tunnels. Of course, this reconfiguration must happen without affecting other tenants within the cloud. | ||
| + | |||
| + | Allow the service provider to select and plug in third-party technologies as appropriate. This may be for extended features, improved performance, or reduced complexity or cost. | ||
| + | |||
| + | The extent to which customers can manipulate their own network infrastructure will depend upon the service provider and the underlying technologies that they have deployed. It is a further goal of this blueprint to gracefully manage the disparity between various deployments. | ||
| + | |||
| + | Additionally, some of the topologies proposed below imply that the compute layer must support multiple network interfaces per VM. This is not supported today, and must be added as part of this work. | ||
| + | |||
| + | == Glossary == | ||
| + | |||
| + | The customer-facing service proposed by this blueprint shall be named "openstack-networking" for the purpose of this document, to distinguish it from the existing nova-network. | ||
| + | |||
| + | The customer-facing API exposed by openstack-networking will be called the OpenStack Networking API for the purpose of this document. | ||
| + | |||
| + | Neither name is important, and we do not have to stick with these. | ||
| + | |||
| + | == Use Cases == | ||
| + | |||
| + | === Use case 1: Isolated per-tenant networks === | ||
| + | |||
| + | Each tenant has an isolated network, which the tenant accesses via a VPN gateway. Tenants are free to do whatever they want on their network, because it is completely isolated from those of other tenants. | ||
| + | |||
| + | This is the NASA Nebula model today. | ||
| + | |||
| + | This is currently implemented using one VLAN per tenant, and with one instance of nova-network per tenant to act as the VPN gateway. Note that this same model could equally be implemented with different technologies (e.g. a commercial VPN gateway, or using GRE tunnels instead of VLANs for isolation). One aim of this blueprint is to consider the model independently from the underlying implementation technology. | ||
| + | |||
| + | === Use case 2: Direct internet connections === | ||
| + | |||
| + | Each VM has a single public IP address and is connected directly to the Internet. Tenants may not choose their IP address or manage anything about the network topology. | ||
| + | |||
| + | This is the Rackspace Cloud model today. | ||
| + | |||
| + | === Use case 3: Firewall service === | ||
| + | |||
| + | Like Use case 1, but the VPN gateway is replaced by a firewall service that can be managed by the customer through the OpenStack Networking API. The public side of the firewall would usually be connected directly to the Internet. The firewall itself is provided by the service provider. | ||
| + | |||
| + | === Use case 4: Customer-owned gateway === | ||
| + | |||
| + | Like use cases 1 and 3, but instead of the gateway being a service provided by the cloud and managed through the Networking API, the customer instead provides their own gateway, as a virtual appliance. | ||
| + | |||
| + | The customer would have most VMs attached to their isolated network, but would be able to configure one (or more) of their VMs to have two interfaces, one connected to the isolated network, and one connected to the Internet. The customer would be responsible for the software within the publicly-connected VMs, and would presumably install a gateway or firewall therein. | ||
| + | |||
| + | === Use case 5: Multi-tier applications === | ||
| + | |||
| + | Like use case 4, but rather than running a gateway or a firewall, the customer is expected to run web servers instead. These would serve content to the public interfaces, and would contact the backend tiers via the private network. | ||
== Requirements == | == Requirements == | ||
| + | |||
| + | R1. Add a first-class, customer-facing service for management and configuration of network infrastructure via a RESTful API. | ||
| + | |||
| + | Rn. Add support to nova-compute for multiple network interfaces per VM. Add this to all supported virtualization technologies (KVM/libvirt, XenAPI, Hyper-V, ESX). | ||
| + | |||
| + | ... lots more coming here don't worry! | ||
== Non-requirements == | == Non-requirements == | ||
Revision as of 01:04, 1 February 2011
This blueprint is being redrafted. Ewan Mellor will be happy to hear from you if you wish to contribute. Nothing here is committed.
- Launchpad Nova blueprint: NovaSpec:bexar-network-service
- Created: 31 January 2011
- Last updated: 1 February 2011
- Drafter: Ewan Mellor
- Contributors: Patrick Ancillotti, Erik Carlin, Dan Mihai Dumitriu, Ram Durairaj, Søren Hansen, Koji Iida, Hisaharu Ishii, Masanori Itoh, Adam Johnson, Youcef Laribi, Romain Lenglet, Salvatore Orlando, John Purrier, Andy Smith, Troy Toman, Dan Wendlandt, Zhixue Wu
Goals
Add a first-class, customer-facing service for the management of network infrastructure within an OpenStack cloud.
Allow the customer to configure rich network topologies within the cloud. These topologies will include private connections between VMs, and connections between VMs and network services such as load-balancers, firewalls, and tunnels. Of course, this reconfiguration must happen without affecting other tenants within the cloud.
Allow the service provider to select and plug in third-party technologies as appropriate. This may be for extended features, improved performance, or reduced complexity or cost.
The extent to which customers can manipulate their own network infrastructure will depend upon the service provider and the underlying technologies that they have deployed. It is a further goal of this blueprint to gracefully manage the disparity between various deployments.
Additionally, some of the topologies proposed below imply that the compute layer must support multiple network interfaces per VM. This is not supported today, and must be added as part of this work.
Glossary
The customer-facing service proposed by this blueprint shall be named "openstack-networking" for the purpose of this document, to distinguish it from the existing nova-network.
The customer-facing API exposed by openstack-networking will be called the OpenStack Networking API for the purpose of this document.
Neither name is important, and we do not have to stick with these.
Use Cases
Use case 1: Isolated per-tenant networks
Each tenant has an isolated network, which the tenant accesses via a VPN gateway. Tenants are free to do whatever they want on their network, because it is completely isolated from those of other tenants.
This is the NASA Nebula model today.
This is currently implemented using one VLAN per tenant, and with one instance of nova-network per tenant to act as the VPN gateway. Note that this same model could equally be implemented with different technologies (e.g. a commercial VPN gateway, or using GRE tunnels instead of VLANs for isolation). One aim of this blueprint is to consider the model independently from the underlying implementation technology.
Use case 2: Direct internet connections
Each VM has a single public IP address and is connected directly to the Internet. Tenants may not choose their IP address or manage anything about the network topology.
This is the Rackspace Cloud model today.
Use case 3: Firewall service
Like Use case 1, but the VPN gateway is replaced by a firewall service that can be managed by the customer through the OpenStack Networking API. The public side of the firewall would usually be connected directly to the Internet. The firewall itself is provided by the service provider.
Use case 4: Customer-owned gateway
Like use cases 1 and 3, but instead of the gateway being a service provided by the cloud and managed through the Networking API, the customer instead provides their own gateway, as a virtual appliance.
The customer would have most VMs attached to their isolated network, but would be able to configure one (or more) of their VMs to have two interfaces, one connected to the isolated network, and one connected to the Internet. The customer would be responsible for the software within the publicly-connected VMs, and would presumably install a gateway or firewall therein.
Use case 5: Multi-tier applications
Like use case 4, but rather than running a gateway or a firewall, the customer is expected to run web servers instead. These would serve content to the public interfaces, and would contact the backend tiers via the private network.
Requirements
R1. Add a first-class, customer-facing service for management and configuration of network infrastructure via a RESTful API.
Rn. Add support to nova-compute for multiple network interfaces per VM. Add this to all supported virtualization technologies (KVM/libvirt, XenAPI, Hyper-V, ESX).
... lots more coming here don't worry!
Non-requirements
Assumptions
Rationale
Design
QA
Future
Development Resources
Release Note
Discussion
Etherpad from discussion session at Bexar design summit: http://etherpad.openstack.org/i5aSxrDeUU
Slide deck from discussion session at Bexar design summit: http://www.slideshare.net/danwent/bexar-network-blueprint
