~rlane/nova/ldapimprovements

« back to all changes in this revision

Viewing changes to doc/source/devref/network.rst

  • Committer: Ryan Lane
  • Date: 2010-11-24 15:46:32 UTC
  • mfrom: (382.48.1 trunk)
  • Revision ID: laner@controller-20101124154632-zh7kwjuyyd02a2lh
MergeĀ fromĀ trunk

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
1
..
2
2
      Copyright 2010 United States Government as represented by the
3
 
      Administrator of the National Aeronautics and Space Administration. 
 
3
      Administrator of the National Aeronautics and Space Administration.
4
4
      All Rights Reserved.
5
5
 
6
6
      Licensed under the Apache License, Version 2.0 (the "License"); you may
15
15
      License for the specific language governing permissions and limitations
16
16
      under the License.
17
17
 
18
 
nova Networking
19
 
================
 
18
Networking
 
19
==========
 
20
 
 
21
.. todo:: 
 
22
 
 
23
    * document hardware specific commands (maybe in admin guide?) (todd)
 
24
    * document a map between flags and managers/backends (todd)
 
25
 
 
26
 
 
27
The :mod:`nova.network.manager` Module
 
28
--------------------------------------
 
29
 
 
30
.. automodule:: nova.network.manager
 
31
    :noindex:
 
32
    :members:
 
33
    :undoc-members:
 
34
    :show-inheritance:
 
35
 
 
36
The :mod:`nova.network.linux_net` Driver
 
37
----------------------------------------
 
38
 
 
39
.. automodule:: nova.network.linux_net
 
40
    :noindex:
 
41
    :members:
 
42
    :undoc-members:
 
43
    :show-inheritance:
 
44
 
 
45
Tests
 
46
-----
 
47
 
 
48
The :mod:`network_unittest` Module
 
49
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
50
 
 
51
.. automodule:: nova.tests.network_unittest
 
52
    :noindex:
 
53
    :members:
 
54
    :undoc-members:
 
55
    :show-inheritance:
 
56
 
 
57
 
 
58
Legacy docs
 
59
-----------
20
60
 
21
61
The nova networking components manage private networks, public IP addressing, VPN connectivity, and firewall rules.
22
62
 
24
64
----------
25
65
There are several key components:
26
66
 
27
 
* NetworkController (Manages address and vlan allocation) 
 
67
* NetworkController (Manages address and vlan allocation)
28
68
* RoutingNode (NATs public IPs to private IPs, and enforces firewall rules)
29
69
* AddressingNode (runs DHCP services for private networks)
30
70
* BridgingNode (a subclass of the basic nova ComputeNode)
31
71
* TunnelingNode (provides VPN connectivity)
32
 
  
 
72
 
33
73
Component Diagram
34
74
-----------------
35
75
 
36
76
Overview::
37
77
 
38
 
                                (PUBLIC INTERNET) 
 
78
                                (PUBLIC INTERNET)
39
79
                                 |              \
40
80
                                / \             / \
41
81
                  [RoutingNode] ... [RN]    [TunnelingNode] ... [TN]
42
82
                        |             \    /       |              |
43
83
                        |            < AMQP >      |              |
44
 
 [AddressingNode]--  (VLAN) ...         |        (VLAN)...    (VLAN)      --- [AddressingNode] 
 
84
 [AddressingNode]--  (VLAN) ...         |        (VLAN)...    (VLAN)      --- [AddressingNode]
45
85
                        \               |           \           /
46
86
                       / \             / \         / \         / \
47
87
                        [BridgingNode] ...          [BridgingNode]
48
 
                                             
49
 
                                             
 
88
 
 
89
 
50
90
                  [NetworkController]   ...    [NetworkController]
51
91
                                    \          /
52
92
                                      < AMQP >
53
93
                                         |
54
94
                                        / \
55
 
                       [CloudController]...[CloudController]                  
 
95
                       [CloudController]...[CloudController]
56
96
 
57
 
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).       
 
97
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).
58
98
 
59
99
State Model
60
100
-----------
61
101
Network State consists of the following facts:
62
102
 
63
103
* VLAN assignment (to a project)
64
 
* Private Subnet assignment (to a security group) in a VLAN 
 
104
* Private Subnet assignment (to a security group) in a VLAN
65
105
* Private IP assignments (to running instances)
66
106
* Public IP allocations (to a project)
67
107
* Public IP associations (to a private IP / running instance)
68
108
 
69
 
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP).  The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.    
 
109
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP).  The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.
70
110
 
71
111
The Public Traffic Path
72
112
-----------------------
73
 
                                                                                                                                     
 
113
 
74
114
Public Traffic::
75
115
 
76
116
                (PUBLIC INTERNET)
77
117
                       |
78
 
                     <NAT>  <-- [RoutingNode]      
 
118
                     <NAT>  <-- [RoutingNode]
79
119
                       |
80
120
 [AddressingNode] -->  |
81
 
                    ( VLAN )  
 
121
                    ( VLAN )
82
122
                       |    <-- [BridgingNode]
83
123
                       |
84
 
                <RUNNING INSTANCE>   
85
 
 
86
 
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.        
87
 
 
88
 
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).                                           
 
124
                <RUNNING INSTANCE>
 
125
 
 
126
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.
 
127
 
 
128
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).