]>
Commit | Line | Data |
---|---|---|
3c34dd48 BP |
1 | Why Open vSwitch? |
2 | ================= | |
3 | ||
81f9a039 JP |
4 | Hypervisors need the ability to bridge traffic between VMs and with the |
5 | outside world. On Linux-based hypervisors, this used to mean using the | |
6 | built-in L2 switch (the Linux bridge), which is fast and reliable. So, | |
7 | it is reasonable to ask why Open vSwitch is used. | |
3c34dd48 BP |
8 | |
9 | The answer is that Open vSwitch is targeted at multi-server | |
81f9a039 | 10 | virtualization deployments, a landscape for which the previous stack is |
3c34dd48 BP |
11 | not well suited. These environments are often characterized by highly |
12 | dynamic end-points, the maintenance of logical abstractions, and | |
13 | (sometimes) integration with or offloading to special purpose switching | |
14 | hardware. | |
15 | ||
16 | The following characteristics and design considerations help Open | |
17 | vSwitch cope with the above requirements. | |
18 | ||
19 | * The mobility of state: All network state associated with a network | |
20 | entity (say a virtual machine) should be easily identifiable and | |
21 | migratable between different hosts. This may include traditional | |
22 | "soft state" (such as an entry in an L2 learning table), L3 forwarding | |
23 | state, policy routing state, ACLs, QoS policy, monitoring | |
29089a54 | 24 | configuration (e.g. NetFlow, IPFIX, sFlow), etc. |
3c34dd48 BP |
25 | |
26 | Open vSwitch has support for both configuring and migrating both slow | |
27 | (configuration) and fast network state between instances. For | |
28 | example, if a VM migrates between end-hosts, it is possible to not | |
29 | only migrate associated configuration (SPAN rules, ACLs, QoS) but any | |
30 | live network state (including, for example, existing state which | |
31 | may be difficult to reconstruct). Further, Open vSwitch state is | |
32 | typed and backed by a real data-model allowing for the development of | |
33 | structured automation systems. | |
34 | ||
35 | * Responding to network dynamics: Virtual environments are often | |
36 | characterized by high-rates of change. VMs coming and going, VMs | |
37 | moving backwards and forwards in time, changes to the logical network | |
38 | environments, and so forth. | |
39 | ||
40 | Open vSwitch supports a number of features that allow a network | |
29089a54 RL |
41 | control system to respond and adapt as the environment changes. |
42 | This includes simple accounting and visibility support such as | |
43 | NetFlow, IPFIX, and sFlow. But perhaps more useful, Open vSwitch | |
44 | supports a network state database (OVSDB) that supports remote | |
45 | triggers. Therefore, a piece of orchestration software can "watch" | |
46 | various aspects of the network and respond if/when they change. | |
47 | This is used heavily today, for example, to respond to and track VM | |
48 | migrations. | |
3c34dd48 BP |
49 | |
50 | Open vSwitch also supports OpenFlow as a method of exporting remote | |
51 | access to control traffic. There are a number of uses for this | |
52 | including global network discovery through inspection of discovery | |
53 | or link-state traffic (e.g. LLDP, CDP, OSPF, etc.). | |
54 | ||
55 | * Maintenance of logical tags: Distributed virtual switches (such as | |
56 | VMware vDS and Cisco's Nexus 1000V) often maintain logical context | |
57 | within the network through appending or manipulating tags in network | |
58 | packets. This can be used to uniquely identify a VM (in a manner | |
59 | resistant to hardware spoofing), or to hold some other context that | |
60 | is only relevant in the logical domain. Much of the problem of | |
61 | building a distributed virtual switch is to efficiently and correctly | |
62 | manage these tags. | |
63 | ||
64 | Open vSwitch includes multiple methods for specifying and maintaining | |
65 | tagging rules, all of which are accessible to a remote process for | |
66 | orchestration. Further, in many cases these tagging rules are stored | |
67 | in an optimized form so they don't have to be coupled with a | |
68 | heavyweight network device. This allows, for example, thousands of | |
69 | tagging or address remapping rules to be configured, changed, and | |
70 | migrated. | |
71 | ||
72 | In a similar vein, Open vSwitch supports a GRE implementation that can | |
73 | handle thousands of simultaneous GRE tunnels and supports remote | |
74 | configuration for tunnel creation, configuration, and tear-down. | |
75 | This, for example, can be used to connect private VM networks in | |
76 | different data centers. | |
77 | ||
78 | * Hardware integration: Open vSwitch's forwarding path (the in-kernel | |
79 | datapath) is designed to be amenable to "offloading" packet processing | |
80 | to hardware chipsets, whether housed in a classic hardware switch | |
81 | chassis or in an end-host NIC. This allows for the Open vSwitch | |
82 | control path to be able to both control a pure software | |
83 | implementation or a hardware switch. | |
84 | ||
85 | There are many ongoing efforts to port Open vSwitch to hardware | |
86 | chipsets. These include multiple merchant silicon chipsets (Broadcom | |
81f9a039 JP |
87 | and Marvell), as well as a number of vendor-specific platforms. (The |
88 | PORTING file discusses how one would go about making such a port.) | |
3c34dd48 BP |
89 | |
90 | The advantage of hardware integration is not only performance within | |
91 | virtualized environments. If physical switches also expose the Open | |
92 | vSwitch control abstractions, both bare-metal and virtualized hosting | |
93 | environments can be managed using the same mechanism for automated | |
94 | network control. | |
95 | ||
96 | In many ways, Open vSwitch targets a different point in the design space | |
81f9a039 | 97 | than previous hypervisor networking stacks, focusing on the need for |
3c34dd48 BP |
98 | automated and dynamic network control in large-scale Linux-based |
99 | virtualization environments. | |
100 | ||
101 | The goal with Open vSwitch is to keep the in-kernel code as small as | |
102 | possible (as is necessary for performance) and to re-use existing | |
103 | subsystems when applicable (for example Open vSwitch uses the existing | |
81f9a039 JP |
104 | QoS stack). As of Linux 3.3, Open vSwitch is included as a part of the |
105 | kernel and packaging for the userspace utilities are available on most | |
106 | popular distributions. |