Improve of network part
Add part about Nova Network. Extend a comparison Neutron vs. NovaNet. Resize SVGs with network schemas but they still not work in PDF. Reformat "Limitations" section.
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
Before Width: | Height: | Size: 53 KiB After Width: | Height: | Size: 53 KiB |
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
@ -9,29 +9,9 @@ Network Architecture
|
|||||||
|
|
||||||
.. contents :local:
|
.. contents :local:
|
||||||
|
|
||||||
The current architecture assumes the presence of 3 NICs, but it can be
|
For better network performance and manageability, Fuel place different types
|
||||||
customized for two or 4+ network interfaces. Most servers arebuilt with at least
|
of traffic into separate networks. This section describes how to distribute
|
||||||
two network interfaces. In this case, let's consider a typical example of three
|
the network traffic in an OpenStack cluster.
|
||||||
NIC cards. They're utilized as follows:
|
|
||||||
|
|
||||||
**eth0**:
|
|
||||||
The internal management network, used for communication with Puppet & Cobbler
|
|
||||||
|
|
||||||
**eth1**:
|
|
||||||
The public network, and floating IPs assigned to VMs
|
|
||||||
|
|
||||||
**eth2**:
|
|
||||||
The private network, for communication between OpenStack VMs, and the
|
|
||||||
bridge interface (VLANs)
|
|
||||||
|
|
||||||
In the multi-host networking mode, you can choose between the FlatDHCPManager
|
|
||||||
and VlanManager network managers in OpenStack. The figure below illustrates the
|
|
||||||
relevant nodes and networks.
|
|
||||||
|
|
||||||
.. image:: /_images/080-networking-diagram_svg.jpg
|
|
||||||
:align: center
|
|
||||||
|
|
||||||
Lets take a closer look at each network and how its used within the environment.
|
|
||||||
|
|
||||||
.. index:: Public Network
|
.. index:: Public Network
|
||||||
|
|
||||||
@ -40,18 +20,16 @@ Public Network
|
|||||||
|
|
||||||
This network allows inbound connections to VMs from the outside world (allowing
|
This network allows inbound connections to VMs from the outside world (allowing
|
||||||
users to connect to VMs from the Internet). It also allows outbound connections
|
users to connect to VMs from the Internet). It also allows outbound connections
|
||||||
from VMs to the outside world.
|
from VMs to the outside world. For security reasons, the public network is usually
|
||||||
|
isolated from other networks in cluster. The word "Public" means that these addresses
|
||||||
|
can be used to communicate with cluster and its VMs from outside of cluster.
|
||||||
|
|
||||||
For security reasons, the public network is usually isolated from the private
|
To enable external access to VMs, the public network provides the address space
|
||||||
network and internal (management) network. Typically, it's a single C class
|
|
||||||
network from your globally routed or private network range.
|
|
||||||
|
|
||||||
To enable Internet access to VMs, the public network provides the address space
|
|
||||||
for the floating IPs assigned to individual VM instances by the project
|
for the floating IPs assigned to individual VM instances by the project
|
||||||
administrator. Nova-network or Neutron (formerly Quantum) services can then
|
administrator. Nova Network or Neutron services can then
|
||||||
configure this address on the public network interface of the Network controller
|
configure this address on the public network interface of the Network controller
|
||||||
node. Environments based on nova-network use iptables to create a
|
node. E.g. environments based on Nova Network use iptables to create a
|
||||||
Destination NAT from this address to the fixed IP of the corresponding VM
|
Destination NAT from this address to the private IP of the corresponding VM
|
||||||
instance through the appropriate virtual bridge interface on the Network
|
instance through the appropriate virtual bridge interface on the Network
|
||||||
controller node.
|
controller node.
|
||||||
|
|
||||||
@ -60,7 +38,7 @@ routed address space for VMs. The IP address from the public network that has
|
|||||||
been assigned to a compute node is used as the source for the Source NAT
|
been assigned to a compute node is used as the source for the Source NAT
|
||||||
performed for traffic going from VM instances on the compute node to Internet.
|
performed for traffic going from VM instances on the compute node to Internet.
|
||||||
|
|
||||||
The public network also provides VIPs for Endpoint nodes, which are used to
|
The public network also provides Virtual IPs for Endpoint nodes, which are used to
|
||||||
connect to OpenStack services APIs.
|
connect to OpenStack services APIs.
|
||||||
|
|
||||||
.. index:: Internal Network, Management Network
|
.. index:: Internal Network, Management Network
|
||||||
@ -76,17 +54,36 @@ networks for security reasons.
|
|||||||
The internal network can also be used for serving iSCSI protocol exchanges
|
The internal network can also be used for serving iSCSI protocol exchanges
|
||||||
between Compute and Storage nodes.
|
between Compute and Storage nodes.
|
||||||
|
|
||||||
This network usually is a single C class network from your private, non-globally
|
|
||||||
routed IP address range.
|
|
||||||
|
|
||||||
.. index:: Private Network
|
.. index:: Private Network
|
||||||
|
|
||||||
Private Network
|
Private Network
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
The private network facilitates communication between each tenant's VMs. Private
|
The private network facilitates communication between each tenant's VMs. Private
|
||||||
network address spaces are part of the enterprise network address space. Fixed
|
network address spaces are not a part of the enterprise network address space. Fixed
|
||||||
IPs of virtual instances are directly accessible from the rest of Enterprise network.
|
IPs of virtual instances are directly unaccessible from the rest of Enterprise network.
|
||||||
|
|
||||||
|
NIC usage
|
||||||
|
---------
|
||||||
|
|
||||||
|
The current architecture assumes the presence of 3 NICs, but it can be
|
||||||
|
customized for two or 4+ network interfaces. Most servers are built with at least
|
||||||
|
two network interfaces. In this case, let's consider a typical example of three
|
||||||
|
NIC cards. They're utilized as follows:
|
||||||
|
|
||||||
|
**eth0**:
|
||||||
|
The internal management network, used for communication with Puppet & Cobbler
|
||||||
|
|
||||||
|
**eth1**:
|
||||||
|
The public network, and floating IPs assigned to VMs
|
||||||
|
|
||||||
|
**eth2**:
|
||||||
|
The private network, for communication between OpenStack VMs, and the
|
||||||
|
bridge interface (VLANs)
|
||||||
|
|
||||||
|
The figure below illustrates the relevant nodes and networks in Neutron VLAN mode.
|
||||||
|
|
||||||
|
.. image:: /_images/080-networking-diagram_svg.jpg
|
||||||
|
:align: center
|
||||||
|
|
||||||
|
|
||||||
The private network can be segmented into separate isolated VLANs, which are
|
|
||||||
managed by nova-network or Neutron (formerly Quantum) services.
|
|
||||||
|
@ -1,28 +1,8 @@
|
|||||||
.. index:: Neutron vs. nova-network, Quantum vs. nova-network
|
.. index:: Neutron vs. nova-network, Quantum vs. nova-network
|
||||||
|
|
||||||
Neutron vs. nova-network
|
Neutron vs. Nova Network
|
||||||
========================
|
========================
|
||||||
|
|
||||||
Neutron (formerly Quantum) is a service which provides Networking-as-a-Service
|
|
||||||
functionality in OpenStack. It has a rich tenant-facing API for defining
|
|
||||||
network connectivity and addressing in the cloud, and gives operators the
|
|
||||||
ability to leverage different networking technologies to power their cloud
|
|
||||||
networking.
|
|
||||||
|
|
||||||
There are various deployment use cases for Neutron. Fuel supports the most
|
|
||||||
common of them, called Per-tenant Routers with Private Networks.
|
|
||||||
Each tenant has a virtual Neutron router with one or more private networks,
|
|
||||||
which can communicate with the outside world.
|
|
||||||
This allows full routing isolation for each tenant private network.
|
|
||||||
|
|
||||||
Neutron is not, however, required in order to run an OpenStack environment. If
|
|
||||||
you don't need (or want) this added functionality, it's perfectly acceptable to
|
|
||||||
continue using nova-network.
|
|
||||||
|
|
||||||
In order to deploy Neutron, you need to enable it in the Fuel configuration.
|
|
||||||
Fuel sets up Neutron components on each of the controllers to act as a router
|
|
||||||
in HA (if deploying in HA mode).
|
|
||||||
|
|
||||||
Terminology
|
Terminology
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
@ -46,26 +26,73 @@ Terminology
|
|||||||
|
|
||||||
Overview
|
Overview
|
||||||
--------
|
--------
|
||||||
OpenStack networking with Neutron (Quantum) has some differences from
|
|
||||||
Nova-network. Neutron is able to virtualize and manage both layer 2 (logical)
|
With Fuel you can chose between two network providers: Nova Network and Neutron.
|
||||||
|
|
||||||
|
Nova Network
|
||||||
|
------------
|
||||||
|
|
||||||
|
Nova Network is based on standart Linux bridges and uses firewall of the host node.
|
||||||
|
Nova Network was a default network provider in OpenStack before Grizzly release.
|
||||||
|
It can use two network managers: Flat DHCP Manager and Vlan Manager.
|
||||||
|
|
||||||
|
* **Flat DHCP Manager** keeps all tenants in one L2 broadcast segment, so there is nothing
|
||||||
|
about security and tenant isolation. If you want to make a quick and simple
|
||||||
|
cluster you can use this manager.
|
||||||
|
|
||||||
|
* **Vlan Manager** uses VLANs to separate tenants from each other.
|
||||||
|
|
||||||
|
Because of Nova Network uses the host node's kernel for an IP routing,
|
||||||
|
the IP address spaces inside of tenants can't be intersected.
|
||||||
|
Also you can not apply restrictions to a tenant's internal traffic at cluster level.
|
||||||
|
All traffic filtering in Nova Network applies at the border between external network and
|
||||||
|
tenant's internal network.
|
||||||
|
|
||||||
|
Neutron
|
||||||
|
-------
|
||||||
|
|
||||||
|
Neutron (formerly Quantum) is a service which provides Networking-as-a-Service
|
||||||
|
functionality in OpenStack. It has a rich tenant-facing API for defining
|
||||||
|
network connectivity and addressing in the cloud, and gives operators the
|
||||||
|
ability to leverage different networking technologies to power their cloud
|
||||||
|
networking.
|
||||||
|
|
||||||
|
There are various deployment use cases for Neutron. Fuel supports the most
|
||||||
|
common of them, called Per-tenant Routers with Private Networks.
|
||||||
|
Each tenant has a virtual Neutron router with one or more private networks,
|
||||||
|
which can communicate with the outside world.
|
||||||
|
This allows full routing isolation for each tenant private network.
|
||||||
|
|
||||||
|
Neutron is not, however, required in order to run an OpenStack environment. If
|
||||||
|
you don't need (or want) this added functionality, it's perfectly acceptable to
|
||||||
|
continue using Nova Network.
|
||||||
|
|
||||||
|
In order to deploy Neutron, you need to enable it in the Fuel configuration.
|
||||||
|
Fuel sets up Neutron components on each of the controllers to act as a router
|
||||||
|
in HA (if deploying in HA mode).
|
||||||
|
|
||||||
|
OpenStack networking with Neutron has some differences from
|
||||||
|
Nova Network. Neutron is able to virtualize and manage both layer 2 (logical)
|
||||||
and layer 3 (network) of the OSI network model, as compared to simple layer 3
|
and layer 3 (network) of the OSI network model, as compared to simple layer 3
|
||||||
virtualization provided by nova-network. This is the main difference between
|
virtualization provided by Nova Network. This is the main difference between
|
||||||
the two networking models for OpenStack. Virtual networks (one or more) can be
|
the two networking models for OpenStack. Virtual networks (one or more) can be
|
||||||
created for a single tenant, forming an isolated L2 network called a
|
created for a single tenant, forming an isolated L2 network called a
|
||||||
"private network". Each private network can support one or many IP subnets.
|
"private network". Each private network can support one or many IP subnets.
|
||||||
Private networks can be segmented using two different technologies:
|
Private networks can be segmented using two different technologies:
|
||||||
|
|
||||||
* **VLAN segmentation** "Private network" traffic is managed by
|
* **VLAN segmentation** "Private network" traffic is managed by Neutron
|
||||||
Neutron by the use of a dedicated network adapter. This network adapter must be
|
by the use of a dedicated network adapter. This network segment also must be
|
||||||
attached to a untagged network port. This network segment also must be
|
reserved only for Neutron on each host (Computes and Controllers).
|
||||||
reserved only for Neutron on each host (Computes and Controllers). You should
|
|
||||||
not use any other 802.1q VLANs on this network for other purposes.
|
|
||||||
Additionally, each private network requires its own dedicated VLAN, selected
|
Additionally, each private network requires its own dedicated VLAN, selected
|
||||||
from a given range configured in Fuel UI.
|
from a given range configured in Fuel UI.
|
||||||
* **GRE segmentation** In this mode of operation, Neutron does not
|
* **GRE segmentation** In this mode of operation, Neutron does not
|
||||||
require a dedicated network adapter. Neutron builds a mesh of GRE tunnels from
|
require a dedicated network adapter. Neutron builds a mesh of GRE tunnels from
|
||||||
each compute node and controller nodes to every other node. Private networks
|
each compute node and controller nodes to every other node. Private networks
|
||||||
for each tenant make use of this mesh for isolated traffic.
|
for each tenant make use of this mesh for isolated traffic.
|
||||||
|
The good point for using GRE segmentation is when you don't have enough
|
||||||
|
free VLAN ranges in your network backbone or single L2 segment for all nodes
|
||||||
|
cannot be established. But GRE processing eats system resources a lot as well
|
||||||
|
as network performance.
|
||||||
|
|
||||||
It is important to note:
|
It is important to note:
|
||||||
|
|
||||||
@ -76,7 +103,7 @@ It is important to note:
|
|||||||
and public Openstack API.
|
and public Openstack API.
|
||||||
* Is a best if you place the Private, Admin, Public and Management networks on a
|
* Is a best if you place the Private, Admin, Public and Management networks on a
|
||||||
separate NIC to ensure that traffic is separated adequately.
|
separate NIC to ensure that traffic is separated adequately.
|
||||||
* Admin and Private networks must be located together on separate NIC from the
|
* Admin and Private networks must be located on separate NICs from the
|
||||||
other networks.
|
other networks.
|
||||||
|
|
||||||
A typical network configuration for Neutron with VLAN segmentation might look
|
A typical network configuration for Neutron with VLAN segmentation might look
|
||||||
@ -94,34 +121,47 @@ like this:
|
|||||||
|
|
||||||
The most likely configuration for different number NICs on cluster nodes:
|
The most likely configuration for different number NICs on cluster nodes:
|
||||||
|
|
||||||
+------+----------------------------------------+----------------------------------------+
|
+------+----------------------------------------+-------------------------------------------+
|
||||||
| NICs | VLAN | GRE |
|
| NICs | VLAN | GRE |
|
||||||
+======+========================================+========================================+
|
+======+========================================+===========================================+
|
||||||
| 2 | Not supported | .. image:: /_images/q32_gre_2nic.svg |
|
| 2 | Not supported | .. image:: /_images/q32_gre_2nic.svg |
|
||||||
| | | :align: center |
|
| | | :align: center |
|
||||||
+------+----------------------------------------+----------------------------------------+
|
| | | :width: 500 |
|
||||||
|
| | | :height: 200 |
|
||||||
|
+------+----------------------------------------+-------------------------------------------+
|
||||||
| 3 | .. image:: /_images/q32_vlan_3nic.svg | .. image:: /_images/q32_gre_3nic.svg |
|
| 3 | .. image:: /_images/q32_vlan_3nic.svg | .. image:: /_images/q32_gre_3nic.svg |
|
||||||
| | :align: center | :align: center |
|
| | :align: center | :align: center |
|
||||||
+------+----------------------------------------+----------------------------------------+
|
| | :width: 500 | :width: 500 |
|
||||||
|
| | :height: 250 | :height: 250 |
|
||||||
|
+------+----------------------------------------+-------------------------------------------+
|
||||||
| 4 | .. image:: /_images/q32_vlan_4nic.svg | .. image:: /_images/q32_gre_4nic.svg |
|
| 4 | .. image:: /_images/q32_vlan_4nic.svg | .. image:: /_images/q32_gre_4nic.svg |
|
||||||
| | :align: center | :align: center |
|
| | :align: center | :align: center |
|
||||||
+------+----------------------------------------+----------------------------------------+
|
| | :width: 500 | :width: 500 |
|
||||||
|
| | :height: 300 | :height: 300 |
|
||||||
|
+------+----------------------------------------+-------------------------------------------+
|
||||||
|
|
||||||
|
|
||||||
Known limitations
|
Known limitations
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
|
* To deploy OpenStack using Neutron with GRE segmentation, each node requires at
|
||||||
|
least 2 NICs.
|
||||||
|
* To deploy OpenStack using Neutron with VLAN segmentation, each node requires
|
||||||
|
at least 3 NICs.
|
||||||
|
|
||||||
* Neutron will not allocate a floating IP range for your tenants. After each
|
* Neutron will not allocate a floating IP range for your tenants. After each
|
||||||
tenant is created, a floating IP range must be created. Note that this does
|
tenant is created, a floating IP range must be created. Note that this does
|
||||||
not prevent Internet connectivity for a tenant's instances, but it would
|
not prevent Internet connectivity for a tenant's instances, but it would
|
||||||
prevent them from receiving incoming connections. You, the administrator,
|
prevent them from receiving incoming connections. You, the administrator,
|
||||||
should assign a floating IP addresses for the tenant. Below are steps you can
|
should assign a floating IP network for the tenant. Below are steps you can
|
||||||
follow to do this:
|
follow to do this:
|
||||||
|
|
||||||
| get admin credentials:
|
::
|
||||||
| # source /root/openrc
|
|
||||||
| get admin tenant-ID:
|
%get admin credentials:
|
||||||
| # keystone tenant-list
|
(bash)# source /root/openrc
|
||||||
|
%get admin tenant-ID:
|
||||||
|
(bash)# keystone tenant-list
|
||||||
|
|
||||||
+----------------------------------+----------+---------+
|
+----------------------------------+----------+---------+
|
||||||
| id | name | enabled |
|
| id | name | enabled |
|
||||||
@ -131,8 +171,8 @@ Known limitations
|
|||||||
| cba7b0ff68ee4985816ac3585c8e23a9 | services | True |
|
| cba7b0ff68ee4985816ac3585c8e23a9 | services | True |
|
||||||
+----------------------------------+----------+---------+
|
+----------------------------------+----------+---------+
|
||||||
|
|
||||||
| create one floating-ip address for admin tenant:
|
%create floating-ip for admin tenant:
|
||||||
| # quantum floatingip-create --tenant-id=b796f91df6b84860a7cd474148fb2229 net04_ext
|
(bash)# quantum floatingip-create --tenant-id=b796f91df6b84860a7cd474148fb2229 net04_ext
|
||||||
|
|
||||||
* You can't combine Private or Admin network with any other networks on one NIC.
|
* You can't combine Private or Admin network with any other networks on one NIC.
|
||||||
* To deploy OpenStack using Neutron with GRE segmentation, each node requires at
|
* To deploy OpenStack using Neutron with GRE segmentation, each node requires at
|
||||||
|
@ -3,7 +3,7 @@
|
|||||||
.. _Swift-and-object-storage-notes:
|
.. _Swift-and-object-storage-notes:
|
||||||
|
|
||||||
Object Storage Deployment
|
Object Storage Deployment
|
||||||
-------------------------
|
=========================
|
||||||
|
|
||||||
.. TODO(mihgen): we need to rewrite this and add info about Ceph
|
.. TODO(mihgen): we need to rewrite this and add info about Ceph
|
||||||
Fuel currently supports several scenarios to deploy the object storage:
|
Fuel currently supports several scenarios to deploy the object storage:
|
||||||
|
@ -3,7 +3,7 @@
|
|||||||
.. _savanna-deployment-label:
|
.. _savanna-deployment-label:
|
||||||
|
|
||||||
Savanna Deployment
|
Savanna Deployment
|
||||||
------------------
|
==================
|
||||||
|
|
||||||
Savanna is a service for launching Hadoop clusters on OpenStack. It is
|
Savanna is a service for launching Hadoop clusters on OpenStack. It is
|
||||||
designed to be vendor-agnostic and currently supports two distributions:
|
designed to be vendor-agnostic and currently supports two distributions:
|
||||||
|