Changes between Version 4 and Version 5 of ReferenceGuide


Ignore:
Timestamp:
Oct 18, 2012 11:08:36 AM (7 years ago)
Author:
Ted Faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReferenceGuide

    v4 v5  
    4343  Override the site configuration and request nodes of ''type1'' (or ''type2'' etc.) as host nodes.
    4444 {{{--end-node-shaping}}}::
    45    Attempt to do end node traffic shaping even in containers connected by VDE switches.  This works with qemu nodes, but not process nodes.  Topologies that include both openvz nodes and qemu nodes that shape traffic should use this.
     45   Attempt to do end node traffic shaping even in containers connected by VDE switches.  This works with qemu nodes, but not process nodes.  Topologies that include both openvz nodes and qemu nodes that shape traffic should use this.  See the [ReferenceGuide#Interconnections:VDEswitchesandlocalnetworking discussion below].
    4646 {{{--vde-switch-shaping}}}::
    47    Do traffic shaping in VDE switches.  Probably the default, but that is controlled in [ReferenceGuide#SiteConfigurationFile the site configuration].
     47   Do traffic shaping in VDE switches.  Probably the default, but that is controlled in [ReferenceGuide#SiteConfigurationFile the site configuration]. See the [ReferenceGuide#Interconnections:VDEswitchesandlocalnetworking discussion below].
    4848 {{{--openvz-diskspace}}}::
    4949   Set the default openvz disk space size.  The suffixes G and M stand for gigabytes and megabytes.
     
    122122Network behavior changes - loss, delay, rate limits -  are introduced into a network of containers using one of two mechanisms: inserting elements into a VDE switch topology or end node traffic shaping.  Inserting elements into the VDE switch topology allows the system to modify the behavior for all packets passing through it.  Generally this means all packets to or from a host, as the container system inserts these elements in the path between the node and the switch.
    123123
    124 This figure shows 3 containers sharing a virtual LAN on a VED switch with no traffic shaping:
     124This figure shows 3 containers sharing a virtual LAN (VLAN) on a VDE switch with no traffic shaping:
    125125
     126[[Image(Unshaped.png)]]
    126127
     128The blue containers connect to the switch and the switch has interconnected their VDE ports into the red shared VLAN.  To add delays to tow of the nodes on that VLAN, the following VDE switch configuration would be used:
    127129
    128 Openvz containers are interconnected through kernel networking directly to support their high efficiency, and because talking to another container implies leaving the physical machine.  They induce network delays through [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem end node traffic shaping].
     130[[Image(shaped.png)]]
    129131
    130 Qemu nodes can support either end node tra
     132The VDE switch connects the containers with shaped traffic to the delay elements, not to the shared VLAN.  The delay elements are on the VLAN and delay all traffic passing through them.  The container system configures the delay elements to delay traffic symmetrically - traffic from the LAN and traffic from teh container are both delayed.  The VDE tools can be configured asymmetrically as well.  This is a very flexible way to interconnect containers.
     133
     134That flexibility incurs a cost in overhead.  Each delay element and the VDE switch is a process, do traffic passing from one delayed nodes to the other experiences 7 context switches: container -> switch, switch -> delay, delay -> switch, switch -> delay, delay -> switch, and switch -> container.
     135
     136The alternative mechanism is to do the traffic shaping inside the nodes, using [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem linux traffic shaping].  In this case, traffic outbound from a container is delayed in the container for the full transit time to the next hop.  The next node does the same.  End-node shaping all happens in the kernel so it is relatively inexpensive at run time.
     137
     138Qemu nodes can make use of either end-node shaping or VDE shaping, and use VDE shaping by default.  The {{{--end-node-shaping}}} and {{{--vde-switch-shaping}}} options to {{{containerize.py}}} forces the choice in qemu.
     139
     140ViewOS processes can only use VDE shaping.  Their network stack emulation is not rich enough to include traffic shaping.
     141
     142Openvz nodes only use end-node traffic shaping.  They have no native VDE support so interconnecting openvz containers to VDE switches would include both extra kernel crossings and extra context switches.  Because a primary attraction of VDE switches is their efficiency, the containers system does not implement VDE interconnections to openvz.
     143
     144Similarly embedded physical nodes use only endnode traffic shaping, as routing outgoing traffic through a virtual switch infrastructure that just connects to its physical interfaces is at best confusing.
     145
     146Unfortunately, endnode traffic shaping and VDE shaping are incompatible.
     147
     148This is primarily of academic interest, unless a researcher wants to impose traffic shaping between containers using incompatible traffic shaping.  There needs to be an unshaped link between the two kinds of traffic shaping.