← Back to branch summary

~0x44/nova/extdoc

« back to all changes in this revision

Viewing changes to doc/source/nova.concepts.rst

  • Committer: NTT PF Lab.
  • Date: 2010-12-24 11:38:49 UTC
  • mto: This revision was merged to the branch mainline in revision 564.
  • Revision ID: openstack@lab.ntt.co.jp-20101224113849-z9nemzmki17bxnvw
Support IPv6

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/source/nova.concepts.rst
1
1
..
2
 
      Copyright 2010-2011 United States Government as represented by the
 
2
      Copyright 2010 United States Government as represented by the
3
3
      Administrator of the National Aeronautics and Space Administration.
4
4
      All Rights Reserved.
5
5
 
64
64
 
65
65
An 'instance' is a word for a virtual machine that runs inside the cloud.
66
66
 
67
 
Concept: Instance Type
68
 
----------------------
69
 
 
70
 
An 'instance type' describes the compute, memory and storage capacity of nova computing instances. In layman terms, this is the size (in terms of vCPUs, RAM, etc.) of the virtual server that you will be launching.
71
 
 
72
67
Concept: System Architecture
73
68
----------------------------
74
69
 
80
75
 
81
76
To achieve the shared-nothing property with multiple copies of the same component, Nova keeps all the cloud system state in a distributed data store. Updates to system state are written into this store, using atomic transactions when required. Requests for system state are read out of this store. In limited cases, the read results are cached within controllers for short periods of time (for example, the current list of system users.) 
82
77
 
83
 
    .. note:: The database schema is available on the `OpenStack Wiki <http://wiki.openstack.org/NovaDatabaseSchema>`_. 
 
78
    .. note:: The database schema is available on the `OpenStack Wiki <http://wiki.openstack.org/NovaDatabaseSchema>_`. 
84
79
 
85
80
Concept: Storage
86
81
----------------
110
105
 
111
106
For example: A user can access api commands allowed to the netadmin role (like allocate_address) only if he has the user-specific netadmin role AND the project-specific netadmin role.
112
107
 
113
 
More information about RBAC can be found in :ref:`auth`.
 
108
More information about RBAC can be found in the :ref:`auth`.
114
109
 
115
110
Concept: API
116
111
------------
134
129
Flat DHCP Mode
135
130
~~~~~~~~~~~~~~
136
131
 
137
 
This is similar to the flat mode, in that all instances are attached to the same bridge.  In this mode Nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default).  It will also run dnsmasq as a dhcpserver listening on this bridge.  Instances receive their fixed IPs by doing a dhcpdiscover.
 
132
This is similar to the flat mode, in that all instances are attached to the same bridge.  In this mode nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default).  It will also run dnsmasq as a dhcpserver listening on this bridge.  Instances receive their fixed IPs by doing a dhcpdiscover.
138
133
 
139
134
VLAN DHCP Mode
140
135
~~~~~~~~~~~~~~
141
136
 
142
 
This is the default networking mode and supports the most features.  For multiple machine installation, it requires a switch that supports host-managed vlan tagging.  In this mode, Nova will create a vlan and bridge for each project.  The project gets a range of private ips that are only accessible from inside the vlan.  In order for a user to access the instances in their project, a special vpn instance (code named :ref:`cloudpipe <cloudpipe>`) needs to be created.  Nova generates a certificate and key for the user to access the vpn and starts the vpn automatically. More information on cloudpipe can be found :ref:`here <cloudpipe>`.
 
137
This is the default networking mode and supports the most features.  For multiple machine installation, it requires a switch that supports host-managed vlan tagging.  In this mode, nova will create a vlan and bridge for each project.  The project gets a range of private ips that are only accessible from inside the vlan.  In order for a user to access the instances in their project, a special vpn instance (code named :ref:`cloudpipe <cloudpipe>`) needs to be created.  Nova generates a certificate and key for the user to access the vpn and starts the vpn automatically. More information on cloudpipe can be found :ref:`here <cloudpipe>`.
143
138
 
144
139
The following diagram illustrates how the communication that occurs between the vlan (the dashed box) and the public internet (represented by the two clouds)
145
140
 
159
154
--------------------
160
155
 
161
156
The nova-manage command is used to perform many essential functions for
162
 
administration and ongoing maintenance of Nova, such as user creation,
 
157
administration and ongoing maintenance of nova, such as user creation,
163
158
vpn management, and much more.
164
159
 
165
 
See :doc:`nova.manage` in the Administration Guide for more details.
 
160
See doc:`nova.manage` in the Administration Guide for more details.
 
161
 
166
162
 
167
163
Concept: Flags
168
164
--------------
169
165
 
170
 
Nova uses python-gflags for a distributed command line system, and the flags can either be set when running a command at the command line or within a flag file. When you install Nova packages for the Austin release, each nova service gets its own flag file. For example, nova-network.conf is used for configuring the nova-network service, and so forth. In releases beyond Austin which was released in October 2010, all flags are set in nova.conf.  
 
166
Nova uses python-gflags for a distributed command line system, and the flags can either be set when running a command at the command line or within flag files. When you install Nova packages, each nova service gets its own flag file. For example, nova-network.conf is used for configuring the nova-network service, and so forth. 
 
167
 
171
168
 
172
169
Concept: Plugins
173
170
----------------
184
181
Concept: IPC/RPC
185
182
----------------
186
183
 
187
 
Nova utilizes the RabbitMQ implementation of the AMQP messaging standard for performing communication between the various Nova services.  This message queuing service is used for both local and remote communication because Nova is designed so that there is no requirement that any of the services exist on the same physical machine.  RabbitMQ in particular is very robust and provides the efficiency and reliability that Nova needs.  More information about RabbitMQ can be found at http://www.rabbitmq.com/. 
 
184
Nova utilizes the RabbitMQ implementation of the AMQP messaging standard for performing communication between the various nova services.  This message queuing service is used for both local and remote communication because Nova is designed so that there is no requirement that any of the services exist on the same physical machine.  RabbitMQ in particular is very robust and provides the efficiency and reliability that Nova needs.  More information about RabbitMQ can be found at http://www.rabbitmq.com/. 
188
185
 
189
186
Concept: Fakes
190
187
--------------