diff options
Diffstat (limited to 'requirements/05-implementation.rst')
| -rw-r--r-- | requirements/05-implementation.rst | 60 |
1 files changed, 24 insertions, 36 deletions
diff --git a/requirements/05-implementation.rst b/requirements/05-implementation.rst index e624a990..e7f35158 100644 --- a/requirements/05-implementation.rst +++ b/requirements/05-implementation.rst @@ -19,11 +19,10 @@ Functional Blocks This section introduces the functional blocks to form the VIM. OpenStack was selected as the candidate for implementation. Inside the VIM, 4 different -building blocks are defined (see :num:`Figure #figure6`). - -.. _figure6: +building blocks are defined (see :numref:`figure6`). .. figure:: images/figure6.png + :name: figure6 :width: 100% Functional blocks @@ -99,8 +98,7 @@ Sequence Fault Management ^^^^^^^^^^^^^^^^ -The detailed work flow for fault management is as follows (see also :num:`Figure -#figure7`): +The detailed work flow for fault management is as follows (see also :numref:`figure7`): 1. Request to subscribe to monitor specific virtual resources. A query filter can be used to narrow down the alarms the Consumer wants to be informed @@ -131,22 +129,19 @@ In order to allow for quick reaction to failures, the time interval between fault detection in step 3 and the corresponding recovery actions in step 7 and 8 shall be less than 1 second. -.. _figure7: - .. figure:: images/figure7.png + :name: figure7 :width: 100% Fault management work flow - -.. _figure8: - .. figure:: images/figure8.png + :name: figure8 :width: 100% Fault management scenario -:num:`Figure #figure8` shows a more detailed message flow (Steps 4 to 6) between +:numref:`figure8` shows a more detailed message flow (Steps 4 to 6) between the 4 building blocks introduced in :ref:`impl_fb`. 4. The Monitor observed a fault in the NFVI and reports the raw fault to the @@ -170,7 +165,7 @@ the 4 building blocks introduced in :ref:`impl_fb`. NFVI Maintenance ^^^^^^^^^^^^^^^^ -The detailed work flow for NFVI maintenance is shown in :num:`Figure #figure9` +The detailed work flow for NFVI maintenance is shown in :numref:`figure9` and has the following steps. Note that steps 1, 2, and 5 to 8a in the NFVI maintenance work flow are very similar to the steps in the fault management work flow and share a similar implementation plan in Release 1. @@ -199,22 +194,19 @@ flow and share a similar implementation plan in Release 1. the queried resource(s). In case the resource is in "maintenance" state, information about the related maintenance operation is returned. -.. _figure9: - .. figure:: images/figure9.png + :name: figure9 :width: 100% NFVI maintenance work flow - -.. _figure10: - .. figure:: images/figure10.png + :name: figure10 :width: 100% NFVI Maintenance implementation plan -:num:`Figure #figure10` shows a more detailed message flow (Steps 4 to 6) +:numref:`figure10` shows a more detailed message flow (Steps 4 to 6) between the 4 building blocks introduced in Section 5.1.. 3. The Administrator is sending a StateChange request to the Controller residing @@ -244,7 +236,7 @@ Implementation plan for OPNFV Release 1 Fault management ^^^^^^^^^^^^^^^^ -:num:`Figure #figure11` shows the implementation plan based on OpenStack and +:numref:`figure11` shows the implementation plan based on OpenStack and related components as planned for Release 1. Hereby, the Monitor can be realized by Zabbix. The Controller is realized by OpenStack Nova [NOVA]_, Neutron [NEUT]_, and Cinder [CIND]_ for compute, network, and storage, @@ -253,7 +245,7 @@ script querying Nova in order to map between physical and virtual resources. The Notifier will be realized by Ceilometer [CEIL]_ receiving failure events on its notification bus. -:num:`Figure #figure12` shows the inner-workings of Ceilometer. After receiving +:numref:`figure12` shows the inner-workings of Ceilometer. After receiving an "event" on its notification bus, first a notification agent will grab the event and send a "notification" to the Collector. The collector writes the notifications received to the Ceilometer databases. @@ -262,8 +254,8 @@ In the existing Ceilometer implementation, an alarm evaluator is periodically polling those databases through the APIs provided. If it finds new alarms, it will evaluate them based on the pre-defined alarm configuration, and depending on the configuration, it will hand a message to the Alarm Notifier, which in -turn will send the alarm message northbound to the Consumer. :num:`Figure -#figure12` also shows an optimized work flow for Ceilometer with the goal to +turn will send the alarm message northbound to the Consumer. :numref:`figure12` +also shows an optimized work flow for Ceilometer with the goal to reduce the delay for fault notifications to the Consumer. The approach is to implement a new notification agent (called "publisher" in Ceilometer terminology) which is directly sending the alarm through the "Notification Bus" @@ -277,17 +269,15 @@ data", and "fired". It is representing a persistent alarm database. In order to realize the Doctor requirements, we need to define new "meters" in the database (see Section 5.6.1). -.. _figure11: - .. figure:: images/figure11.png + :name: figure11 :width: 100% Implementation plan in OpenStack (OPNFV Release 1 ”Arno”) -.. _figure12: - .. figure:: images/figure12.png + :name: figure12 :width: 100% Implementation plan in Ceilometer architecture @@ -367,8 +357,8 @@ Simple information elements: * Metadata (Key-Value-Pairs): provides additional information of a physical resource in maintenance/error state. -Complex information elements (see also UML diagrams in :num:`Figure #figure13` -and :num:`Figure #figure14`): +Complex information elements (see also UML diagrams in :numref:`figure13` +and :numref:`figure14`): * VirtualResourceInfoClass: @@ -453,15 +443,14 @@ Fault management interface This interface allows the VIM to notify the Consumer about a virtual resource that is affected by a fault, either within the virtual resource itself or by the underlying virtualization infrastructure. The messages on this interface are -shown in :num:`Figure #figure13` and explained in detail in the following +shown in :numref:`figure13` and explained in detail in the following subsections. Note: The information elements used in this section are described in detail in Section 5.4. -.. _figure13: - .. figure:: images/figure13.png + :name: figure13 :width: 100% Fault management NB I/F messages @@ -551,12 +540,11 @@ also allows the Administrator to query the state of physical machines, e.g., in order to get details in the current status of the maintenance operation like a firmware update. -The messages defined in these northbound interfaces are shown in :num:`Figure -#figure14` and described in detail in the following subsections. - -.. _figure14: +The messages defined in these northbound interfaces are shown in :numref:`figure14` +and described in detail in the following subsections. .. figure:: images/figure14.png + :name: figure14 :width: 100% NFVI maintenance NB I/F messages @@ -691,7 +679,7 @@ Event Publisher for Alarm (Ceilometer) [*]_ send to the Consumer, whereas one requirement of Doctor is to react on faults as fast as possible. - The existing message flow is shown in :num:`Figure #figure12`: after receiving + The existing message flow is shown in :numref:`figure12`: after receiving an "event", a "notification agent" (i.e. "event publisher") will send a "notification" to a "Collector". The "collector" is collecting the notifications and is updating the Ceilometer "Meter" database that is storing |