root / doc / design-openvswitch.rst @ 0565f862
History | View | Annotate | Download (5.1 kB)
1 |
======================== |
---|---|
2 |
Support for Open vSwitch |
3 |
======================== |
4 |
|
5 |
.. contents:: :depth: 3 |
6 |
|
7 |
This is a design document detailing the implementation of support for |
8 |
Open vSwitch in the Ganeti tool chain. |
9 |
|
10 |
Current state and shortcomings |
11 |
============================== |
12 |
|
13 |
At the moment Ganeti's support for Open vSwitch is very basic and |
14 |
limited to connecting instances to an existing vSwitch. |
15 |
|
16 |
The shortcomings of this approach are: |
17 |
|
18 |
1. The full functionality (VLANs, QoS and trunking) of Open vSwitch is not used. |
19 |
|
20 |
2. Open vSwitch cannot be managed centrally. |
21 |
|
22 |
Proposed changes |
23 |
---------------- |
24 |
1. Implement functions into gnt-cluster and gnt-node to manage Open vSwitch through Ganeti. |
25 |
It should be possible to create, modify and delete vSwitches. The resulting configuration |
26 |
shall automatically be done on all members of the node group, if possible. Connecting Ethernet |
27 |
devices to vSwitches should be managed through this interface as well. |
28 |
|
29 |
2. Implement VLAN-capabilities: Instances shall have additional information for every NIC: VLAN-ID |
30 |
and port type. These are used to determine their type of connection to Open vSwitch. This will |
31 |
require modifying the methods for instance creation and modification |
32 |
|
33 |
3. Implement NIC bonding: Functions to bond NICs for performance improvement, load-balancing and |
34 |
failover should be added. It is preferable to have a configuration option to determine the |
35 |
type of the trunk, as there are different types of trunks (LACP dynamic and static, different |
36 |
failover and load-balancing mechanisms) |
37 |
|
38 |
4. Set QoS level on per instance basis: Instances shall have an additional information: maximum |
39 |
bandwidth and maximum burst. This helps to balance the bandwidth needs between the VMs and to |
40 |
ensure fair sharing of the bandwidth. |
41 |
|
42 |
Automatic configuration of OpenvSwitches |
43 |
++++++++++++++++++++++++++++++++++++++++ |
44 |
Ideally, the OpenvSwitch configuration should be done automatically. |
45 |
|
46 |
This needs to be done on node level, since each node can be individual and a setting on cluster / node group |
47 |
level would be too global is thus not wanted. |
48 |
|
49 |
The task that each node needs to do is: |
50 |
``ovs-vsctl addbr <switchname>`` with <switchname> defaulting to constants.DEFAULT_OVS |
51 |
``ovs-vsctl add-port <switchname> <ethernet device>`` optional: connection to the outside |
52 |
|
53 |
This will give us 2 parameters, that are needed for the OpenvSwitch Setup: |
54 |
switchname: Which will default to constants.DEFAULT_OVS when not given |
55 |
ethernet device: Which will default to None when not given, might be more than one (NIC bonding) |
56 |
|
57 |
These parameters should be set at node level for individuality, _but_ can have defined defaults on cluster |
58 |
and node group level, which can be inherited and thus allow a cluster or node group wide configuration. |
59 |
If a node is setup without parameters, it should use the settings from the parent node group or cluster. If none |
60 |
are given there, defaults should be used. |
61 |
|
62 |
As a first step, this will be implemented for using 1 ethernet device only. Functions for nic bonding will be added |
63 |
later on. |
64 |
|
65 |
Configuration changes for VLANs |
66 |
+++++++++++++++++++++++++++++++ |
67 |
nicparams shall be extended by a value "vlan" that will store the VLAN information for each NIC. |
68 |
This parameter will only be used if nicparams[constants.NIC_MODE] == constants.NIC_MODE_OVS, |
69 |
since it doesn't make sense in other modes. |
70 |
|
71 |
Each VLAN the NIC belongs to shall be stored in this single value. The format of storing this information |
72 |
is the same as the one which is used in Xen 4.3, since Xen 4.3 comes with functionality to support |
73 |
OpenvSwitch. |
74 |
|
75 |
This parameter will, at first, only be implemented for Xen and will have no effects on other hypervisors. |
76 |
Support for KVM will be added in the future. |
77 |
|
78 |
Example: |
79 |
switch1 will connect the VM to the default VLAN of the switch1. |
80 |
switch1.3 means that the VM is connected to an access port of VLAN 3. |
81 |
switch1.2:10:20 means that the VM is connected to a hybrid port on switch1, carrying VLANs 2 untagged and |
82 |
VLANs 10 and 20 tagged. |
83 |
switch1:44:55 means that the VM is connected to a trunk port on switch1, carrying VLANS 44 and 55 |
84 |
|
85 |
This configuration string is split at the dot or colon respectively and stored in nicparams[constants.NIC_LINK] |
86 |
and nicparams[constants.NIC_VLAN] respectively. Dot or colon are stored as well in nicparams[constants.NIC_VLAN]. |
87 |
|
88 |
For Xen hypervisors, this information can be concatenated again and stored in the vif config as |
89 |
the bridge parameter and will be fully compatible with vif-openvswitch as of Xen 4.3. |
90 |
|
91 |
Users of older Xen versions should be able to grab vif-openvswitch from the Xen repo and use it |
92 |
(tested in 4.2). |
93 |
|
94 |
gnt-instance modify shall be able to add or remove single VLANs from the vlan string without users needing |
95 |
to specify the complete new string. |
96 |
|
97 |
NIC bonding |
98 |
+++++++++++ |
99 |
To be done |
100 |
|
101 |
Configuration changes for QoS |
102 |
+++++++++++++++++++++++++++++ |
103 |
Instances shall be extended with configuration options for |
104 |
|
105 |
- maximum bandwidth |
106 |
- maximum burst rate |
107 |
|
108 |
New configuration objects need to be created for the Open vSwitch configuration. |
109 |
|
110 |
All these configuration changes need to be made available on the whole node group. |
111 |
|
112 |
.. vim: set textwidth=72 : |
113 |
.. Local Variables: |
114 |
.. mode: rst |
115 |
.. fill-column: 72 |
116 |
.. End: |