Commit 89fff3bd authored by Christos Stavrakakis's avatar Christos Stavrakakis
Browse files

docs: Update Network Service section

Update Network Service section to containg a reference to Floating IPs,
IPv6 networks and network policy for spawned instances. Also, refactor
the whole section 'Network @ Cyclades level' and add more detail
description to some of the network features. Finally fix some typos, and
references to obsolete usage/settings.
parent b977d687
...@@ -25,72 +25,76 @@ networks are defined from the Cyclades, Ganeti, and Backend persperctive. ...@@ -25,72 +25,76 @@ networks are defined from the Cyclades, Ganeti, and Backend persperctive.
Network @ Cyclades level Network @ Cyclades level
------------------------ ------------------------
Cyclades understands two types of Virtual Networks: Cyclades networks support a range of different options to cover the specific
needs of each deployment.
a) Public Networks
b) Private Networks First of all, as far as visibility and accessibility is concerned, a network
can be either `public` or `private`. Public networks are created by the
Public Networks are created by the administrator via `snf-manage` commands administrator via the command line interface (`snf-manage`) and are visible to
and can be used by all end-users. Each public network is assigned to a all end-users. On the other hand, private networks are created by the end-user
single backend but one backend can have multiple public networks. from the Web UI or the kamaki client and provide isolated Layer 2 connectivity
to the end-user.
Private Networks are created by the end-user from the Web UI or the kamaki
client and provide isolated Layer 2 connectivity to the end-user. With regard Both networks can have an IPv4 subnet or/and an IPv6 subnet along with the
to the fact that a user's VMs may be allocated across different Ganeti clusters corresponding gateway. For IPv4 networks, if the `--dhcp` option is set,
(backends), private networks are created in all backends to ensure VMs Cyclades will treat the IPv4 subnet as an IP pool, and will assign to each VM
connectivity. that is connected to this network an IPv4 address from this pool.
Both types of networks are created dynamically. A public network can also be marked as a floating IP pool with the
`--floating-ip-pool` option. Floating IPs, are IPv4 addresses that can be
From the VM perspective, each NIC is attached to a specific Network. dynamically by added and removed from running VMs. A user can reserve and
release a floating IP address that he can later add and remove it from running
When a new VM is created the backend allocator (in Cyclades) decides in which VMs. Also the user can release a floating IP if it not used by any of his
backend to spawn it. Depending on the chosen backend, Synnefo finds the first VMs.
non-full public Network that exists in the backend. Then attaches the VM's
first NIC to this network. Private networks and floating IPs must be accessible from all instances across
all Ganeti backends. So, such networks must exist in all backends, and
Once the VM is created, the user is able to connect the VM to multiple are dynamically created when new Ganeti backends are added. Specially for
private networks, that himself has already created. private networks, to avoid the overhead of creating the network to all
backends, Cyclades create these networks on demand, when an instance that
A Network can have the following attributes: lives in a backend tries to connect to this network.
- IPv4 subnet (mandatory) The administrator may also want to connect instances to some network, without
- IPv4 gateway supporting floating IPs (e.g. to enforce each VM to be connected to a specific
- IPv6 subnet network). This can be achieved by setting the `DEFAULT_INSTANCE_NETWORKS`
- IPv6 gateway setting to the list of the selected networks. The special keyword
- public/private flag `SNF:ANY_PUBLIC` may be used as a network identifier, to indicate to the system
- flavor to peak any of the public networks that has a free IP address. Public networks
that are not floating IP pools, do not need to exist to all Ganeti backends,
Flavor is a way to abstact infrastructure specific options, that are used to since the Cyclades backend allocator, will route spawned vms to a Ganeti
ensure connectivity and isolation to the VMs connected to the network. It is a backend that the selected networks exist. The administrator can choose in
set of options that eventually will guide scripts to set up rules, while which backends to create the network via the `--backends` command line option.
creating virtual interfaces in the node level. The available flavors and their
options can be found in the Synnefo settings and are configurable. Another distinction between networks is their flavor. Flavor is a way to
abstract infrastructure specific options, that are used to ensure connectivity
and isolation to the VMs connected to the network. It is a set of options that
eventually will guide scripts to set up rules, while creating virtual
interfaces in the node level. Each of these flavors define attributes that will
be used at Ganeti level to create the physical network. These attributes are:
* ``mode``: Whether the network is in 'bridged' or 'routed' mode.
* ``link``: Bridge for 'bridged' networks and routing table for 'routed'
networks. e.g. 'br100', 'rt200'
* ``mac_prefix``: A MAC prefix for the network. e.g. 'aa:00:05'
* ``tags``: A list of tags to be used at the Ganeti level.
To ensure L2 isolation, Synnefo supports two different mechanisms (see also Node To ensure L2 isolation, Synnefo supports two different mechanisms (see also Node
Level section): Level section):
- assigning one physical VLAN per network * assigning one physical VLAN per network
- assigning one MAC prefix per network, so that every NIC attached to this * assigning one MAC prefix per network, so that every NIC attached to this
network will have this prefix. Isolation is then achieved by filtering network will have this prefix. Isolation is then achieved by filtering
rules (via `ebtables`) based on a specific mask (ff:ff:f0:00:00:00, see Node rules (via `ebtables`) based on a specific mask (ff:ff:f0:00:00:00, see Node
Level section for more details). Level section for more details).
Having this in mind and in order to prevent assignment of duplicate VLAN/MAC Having this in mind and in order to prevent assignment of duplicate VLAN/MAC
prefix to different networks, Synnefo supports two types of Pools: prefix to different networks, Synnefo supports two types of Pools:
- Bridge Pool (corresponding to a number of VLANs bridged to those bridges) - Bridge Pool (corresponding to a number of VLANs bridged to those bridges)
- MAC prefix Pool - MAC prefix Pool
For Pool handling refer to the corresponding doc section.
Finally, each supported flavor must declare the following options (see also
Ganeti Level section):
- ``mode`` ('bridged' or 'routed'), For Pool handling refer to the corresponding doc section. To use this pools,
- ``link`` ('br100', 'rt200', 'pool') set either `--link` or `--mac-prefix` to the reserved keyword `pool`.
- ``mac_prefix`` ('aa:00:05', 'pool', None)
- ``tags`` (['ip-less-routed' or 'mac-filtered' or 'physical-vlan' or None])
Existing network flavors are the following: Existing network flavors are the following:
...@@ -103,17 +107,20 @@ PHYSICAL_VLAN bridged 'pool' ``DEFAULT_MAC_PREFI ...@@ -103,17 +107,20 @@ PHYSICAL_VLAN bridged 'pool' ``DEFAULT_MAC_PREFI
CUSTOM bridged ``DEFAULT_BRIDGE`` ``DEFAULT_MAC_PREFIX`` CUSTOM bridged ``DEFAULT_BRIDGE`` ``DEFAULT_MAC_PREFIX``
============== ======= =============================== ====================== ================== ============== ======= =============================== ====================== ==================
``DEFAULT_ROUTING_TABLE``, ``DEFAULT_MAC_PREFIX``, ``DEFAULT_BRIDGE``, ``DEFAULT_MAC_FILTERED_BRIDGE`` ``DEFAULT_ROUTING_TABLE``, ``DEFAULT_MAC_PREFIX``, ``DEFAULT_BRIDGE``,
are all configurable settings in ``/etc/synnefo/20-snf-cyclades-app-api.conf``. 'pool' is used ``DEFAULT_MAC_FILTERED_BRIDGE`` are all configurable settings in
to denote that a link or MAC prefix will be allocated from the corresponging Pool. ``/etc/synnefo/20-snf-cyclades-app-api.conf``. 'pool' is used to denote that a
link or MAC prefix will be allocated from the corresponding Pool. Finally,
most of these attributes, may be overridden when creating networks with
`snf-manage network-create command`.
The administrator is able to create any of the above flavors The administrator is able to create any of the above flavors
and override their default values by explicitly passing mode, link, etc. using and override their default values by explicitly passing mode, link, etc. using
the `snf-manage network-create` command. the `snf-manage network-create` command.
The end-user is allowed to create only networks of flavor ``MAC_FILTERED`` and The administrator can create networks of any flavor, but end-users is allowed
``PHYSICAL_VLAN``. Currently, only ``MAC_FILTERED`` and ``PHYSICAL_VLAN`` can to create via API only networks with flavors that are set in the
use existing pools and cannot be overriden. `API_ENABLED_NETWORK_FLAVORS` setting.
Network @ Ganeti level Network @ Ganeti level
---------------------- ----------------------
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment