Difference between revisions of "Containers/Network virtualization"
m |
(→Approaches) |
||
Line 7: | Line 7: | ||
== Approaches == | == Approaches == | ||
− | + | === Virtualization on the 2nd level (OpenVZ) === | |
− | : For input packets context switching is performed in | + | '''Requirements''': |
− | + | ||
− | : For input packets context switching is | + | The main requirement is that containers should have close to standalone servers networking capabilities. In details: |
− | + | # containers should have own loopback; | |
− | : There is no context switching for packets at all, checks are performed between process and socket contexts. | + | # containers should have ability to setup their own level 3 addresses; |
+ | # containers should have ability to sniff their traffic; | ||
+ | # containers should have ability to setup their own routes; | ||
+ | # containers should have ability to receive multicast/broadcast packets; | ||
+ | # containers should have their own netfilters; | ||
+ | # containers should have at least one level 2 device; | ||
+ | |||
+ | |||
+ | '''Current implementation''': | ||
+ | |||
+ | For input packets context switching is performed in netif_receive_skb(), inherited from the device context. For output, context is inherited from the socket one. | ||
+ | |||
+ | === Virtualization on the 3d level (IBM) === | ||
+ | '''Requirements''': | ||
+ | # One can ran servers in several containers listening on *:port without conflict and __without__ forcing the bind to use the IP address assigned to the container; | ||
+ | # The source address will be filled with the container IP address; | ||
+ | # Keep sockets isolated by namespace; | ||
+ | # have the loopback isolated; | ||
+ | # have the performance near to native as possible; | ||
+ | # have broadcast and multicast working. | ||
+ | |||
+ | '''Current implementation''': | ||
+ | |||
+ | For input packets context switching is inherited from the routing entry, for output - inherited from the socket one. | ||
+ | |||
+ | === Socket virtualization (Linux-VServer) === | ||
+ | '''Requirements''': | ||
+ | # implementation overhead for established tcp connections should be zero; | ||
+ | # FIXME | ||
+ | |||
+ | '''Current implementation''': | ||
+ | |||
+ | There is no context switching for packets at all, checks are performed between process and socket contexts. | ||
== Virtualization table == | == Virtualization table == |
Revision as of 11:28, 8 November 2006
There are a number of approaches to the network virtualization, caused by different requirements for different usages. This page is made in order to summarize them and create solution suitable for all.
Contents
[hide]Usages
Current known usages are:
- Virtual Environments - complete OS environment, with it's own users, groups, filesystems and devices;
- Application Containers - partly isolated environment with application inside.
Approaches
Virtualization on the 2nd level (OpenVZ)
Requirements:
The main requirement is that containers should have close to standalone servers networking capabilities. In details:
- containers should have own loopback;
- containers should have ability to setup their own level 3 addresses;
- containers should have ability to sniff their traffic;
- containers should have ability to setup their own routes;
- containers should have ability to receive multicast/broadcast packets;
- containers should have their own netfilters;
- containers should have at least one level 2 device;
Current implementation:
For input packets context switching is performed in netif_receive_skb(), inherited from the device context. For output, context is inherited from the socket one.
Virtualization on the 3d level (IBM)
Requirements:
- One can ran servers in several containers listening on *:port without conflict and __without__ forcing the bind to use the IP address assigned to the container;
- The source address will be filled with the container IP address;
- Keep sockets isolated by namespace;
- have the loopback isolated;
- have the performance near to native as possible;
- have broadcast and multicast working.
Current implementation:
For input packets context switching is inherited from the routing entry, for output - inherited from the socket one.
Socket virtualization (Linux-VServer)
Requirements:
- implementation overhead for established tcp connections should be zero;
- FIXME
Current implementation:
There is no context switching for packets at all, checks are performed between process and socket contexts.
Virtualization table
This is a summary table in order to show which core networking objects are virtualized/isolated in above approaches or not.
Virtualization approach | network devices | routing tables | network sockets | netfilters |
---|---|---|---|---|
2d level virtualization | v | v/i | v | v |
3d level virtualization | - | i | i | - |
bind filtering | - | - | i | - |
Legend:
- 'v' - virtualized
- 'i' - isolated
- '-' - neither virtualized nor isolated