Merge "Document async status retrieval in NVP plugin"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
1c560e6392
@ -43,6 +43,13 @@
|
|||||||
</abstract>
|
</abstract>
|
||||||
<revhistory>
|
<revhistory>
|
||||||
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
|
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
|
||||||
|
<revision>
|
||||||
|
<date>2013-11-12</date>
|
||||||
|
<revdescription><itemizedlist>
|
||||||
|
<listitem><para>Adds options for tuning operational status synchronization
|
||||||
|
in the NVP plugin.</para></listitem>
|
||||||
|
</itemizedlist></revdescription>
|
||||||
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<date>2013-10-17</date>
|
<date>2013-10-17</date>
|
||||||
<revdescription>
|
<revdescription>
|
||||||
|
|||||||
@ -1716,6 +1716,117 @@
|
|||||||
--provider:physical_network <L3-Gateway-Service-UUID> -provider:segmentation_id <VLAN_ID></userinput></screen>
|
--provider:physical_network <L3-Gateway-Service-UUID> -provider:segmentation_id <VLAN_ID></userinput></screen>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
<section xml:id="section_nicira_nvp_plugin_status_sync">
|
||||||
|
<title>Operational status synchronization in the
|
||||||
|
Nicira NVP plugin</title>
|
||||||
|
<para>Starting with the Havana release, the Nicira NVP plugin
|
||||||
|
provides an asynchronous mechanism for retrieving the
|
||||||
|
operational status for neutron resources from the NVP
|
||||||
|
backend; this applies to <emphasis>network</emphasis>,
|
||||||
|
<emphasis>port</emphasis>, and <emphasis>router</emphasis> resources.</para>
|
||||||
|
<para>The backend is polled periodically, and the status for every resource is
|
||||||
|
retrieved; then the status in the Neutron database is updated only for the
|
||||||
|
resources for which a status change occurred. As operational status is now
|
||||||
|
retrieved asynchronously, performance for <literal>GET</literal> operations is
|
||||||
|
consistently improved.</para>
|
||||||
|
<para>Data to retrieve from the backend are divided in chunks in order to avoid
|
||||||
|
expensive API requests; this is achieved leveraging NVP APIs response paging
|
||||||
|
capabilities. The minimum chunk size can be specified using a configuration
|
||||||
|
option; the actual chunk size is then determined dynamically according to:
|
||||||
|
total number of resources to retrieve, interval between two synchronization task
|
||||||
|
runs, minimum delay between two subsequent requests to the NVP backend.</para>
|
||||||
|
<para>The operational status synchronization can be tuned or disabled using the
|
||||||
|
configuration options reported in the following table; it is however worth
|
||||||
|
noting that the default values will work fine in most cases.</para>
|
||||||
|
<table rules="all">
|
||||||
|
<caption>Configuration options for tuning operational status synchronization
|
||||||
|
in the NVP plugin</caption>
|
||||||
|
<col width="12%"/>
|
||||||
|
<col width="8%"/>
|
||||||
|
<col width="10%"/>
|
||||||
|
<col width="20%"/>
|
||||||
|
<col width="50%"/>
|
||||||
|
<thead>
|
||||||
|
<tr>
|
||||||
|
<th>Option name</th>
|
||||||
|
<th>Group</th>
|
||||||
|
<th>Default value</th>
|
||||||
|
<th>Type and constraints</th>
|
||||||
|
<th>Notes</th>
|
||||||
|
</tr>
|
||||||
|
</thead>
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<td><literal>state_sync_interval</literal></td>
|
||||||
|
<td><literal>nvp_sync</literal></td>
|
||||||
|
<td>120 seconds</td>
|
||||||
|
<td>Integer; no constraint.</td>
|
||||||
|
<td>Interval in seconds between two run of the synchronization task.
|
||||||
|
If the synchronization task takes more than
|
||||||
|
<literal>state_sync_interval</literal> seconds to execute, a
|
||||||
|
new instance of the task is started as soon as the other is
|
||||||
|
completed. Setting the value for this option to 0 will disable
|
||||||
|
the synchronization task.</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><literal>max_random_sync_delay</literal></td>
|
||||||
|
<td><literal>nvp_sync</literal></td>
|
||||||
|
<td>0 seconds</td>
|
||||||
|
<td>Integer. Must not exceed
|
||||||
|
<literal>min_sync_req_delay</literal></td>
|
||||||
|
<td>When different from zero, a random delay between 0 and
|
||||||
|
<literal>max_random_sync_delay</literal> will be added
|
||||||
|
before processing the next chunk.</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><literal>min_sync_req_delay</literal></td>
|
||||||
|
<td><literal>nvp_sync</literal></td>
|
||||||
|
<td>10 seconds</td>
|
||||||
|
<td>Integer. Must not exceed
|
||||||
|
<literal>state_sync_interval</literal>.</td>
|
||||||
|
<td>The value of this option can be tuned according to the observed
|
||||||
|
load on the NVP controllers. Lower values will result in faster
|
||||||
|
synchronization, but might increase the load on the controller
|
||||||
|
cluster.</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><literal>min_chunk_size</literal></td>
|
||||||
|
<td><literal>nvp_sync</literal></td>
|
||||||
|
<td>500 resources</td>
|
||||||
|
<td>Integer; no constraint.</td>
|
||||||
|
<td>Minimum number of resources to retrieve from the backend for
|
||||||
|
each synchronization chunk. The expected number of
|
||||||
|
synchronization chunks is given by the ratio between
|
||||||
|
<literal>state_sync_interval</literal> and
|
||||||
|
<literal>min_sync_req_delay</literal>. This size of a chunk
|
||||||
|
might increase if the total number of resources is such that
|
||||||
|
more than <literal>min_chunk_size</literal> resources must be
|
||||||
|
fetched in one chunk with the current number of chunks.</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><literal>always_read_status</literal></td>
|
||||||
|
<td><literal>nvp_sync</literal></td>
|
||||||
|
<td>False</td>
|
||||||
|
<td>Boolean; no constraint.</td>
|
||||||
|
<td>When this option is enabled, the operational status will always
|
||||||
|
be retrieved from the NVP backend ad every
|
||||||
|
<literal>GET</literal> request. In this case it is advisable
|
||||||
|
to disable the synchronization task.</td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<para>When running multiple Neutron server instances, the status
|
||||||
|
synchronization task should not run on every node; doing so will need to
|
||||||
|
unnecessary traffic towards the NVP backend as well as unnecessary DB
|
||||||
|
operations. The configuration option <literal>state_sync_interval</literal>
|
||||||
|
should therefore be non-zero exclusively on a node designated for backend status
|
||||||
|
synchronization.</para>
|
||||||
|
<para>Explicitly specifying the <emphasis role="italic">status</emphasis> attribute
|
||||||
|
in Neutron API requests (e.g.: <literal>GET
|
||||||
|
/v2.0/networks/<net-id>?fields=status&fields=name</literal>) will
|
||||||
|
always trigger an explicit query to the NVP backend, even when asynchronous
|
||||||
|
state synchronization is enabled.</para>
|
||||||
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section xml:id="section_bigswitch_extensions">
|
<section xml:id="section_bigswitch_extensions">
|
||||||
@ -1827,3 +1938,4 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny</userinput></screen>
|
|||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
<!---->
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user