docs/development/overview/functest_scenario/doctor-scenario-in-functest.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4
   5
   6 Platform overview
   7 """""""""""""""""
   8
   9 Doctor platform provides these features in `Danube Release <https://wiki.opnfv.org/display/SWREL/Danube>`_:
  10
  11 * Immediate Notification
  12 * Consistent resource state awareness for compute host down
  13 * Valid compute host status given to VM owner
  14
  15 These features enable high availability of Network Services on top of
  16 the virtualized infrastructure. Immediate notification allows VNF managers
  17 (VNFM) to process recovery actions promptly once a failure has occurred.
  18
  19 Consistency of resource state is necessary to execute recovery actions
  20 properly in the VIM.
  21
  22 Ability to query host status gives VM owner the possibility to get
  23 consistent state information through an API in case of a compute host
  24 fault.
  25
  26 The Doctor platform consists of the following components:
  27
  28 * OpenStack Compute (Nova)
  29 * OpenStack Telemetry (Ceilometer)
  30 * OpenStack Alarming (Aodh)
  31 * Doctor Inspector
  32 * Doctor Monitor
  33
  34 .. note::
  35     Doctor Inspector and Monitor are sample implementations for reference.
  36
  37 You can see an overview of the Doctor platform and how components interact in
  38 :numref:`figure-p1`.
  39
  40 .. figure:: ./images/figure-p1.png
  41     :name: figure-p1
  42     :width: 100%
  43
  44     Doctor platform and typical sequence
  45
  46 Detailed information on the Doctor architecture can be found in the Doctor
  47 requirements documentation:
  48 http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html
  49
  50 Use case
  51 """"""""
  52
  53 * A consumer of the NFVI wants to receive immediate notifications about faults
  54   in the NFVI affecting the proper functioning of the virtual resources.
  55   Therefore, such faults have to be detected as quickly as possible, and, when
  56   a critical error is observed, the affected consumer is immediately informed
  57   about the fault and can switch over to the STBY configuration.
  58
  59 The faults to be monitored (and at which detection rate) will be configured by
  60 the consumer. Once a fault is detected, the Inspector in the Doctor
  61 architecture will check the resource map maintained by the Controller, to find
  62 out which virtual resources are affected and then update the resources state.
  63 The Notifier will receive the failure event requests sent from the Controller,
  64 and notify the consumer(s) of the affected resources according to the alarm
  65 configuration.
  66
  67 Detailed workflow information is as follows:
  68
  69 * Consumer(VNFM): (step 0) creates resources (network, server/instance) and an
  70   event alarm on state down notification of that server/instance
  71
  72 * Monitor: (step 1) periodically checks nodes, such as ping from/to each
  73   dplane nic to/from gw of node, (step 2) once it fails to send out event
  74   with "raw" fault event information to Inspector
  75
  76 * Inspector: when it receives an event, it will (step 3) mark the host down
  77   ("mark-host-down"), (step 4) map the PM to VM, and change the VM status to
  78   down
  79
  80 * Controller: (step 5) sends out instance update event to Ceilometer
  81
  82 * Notifier: (step 6) Ceilometer transforms and passes the event to Aodh,
  83   (step 7) Aodh will evaluate event with the registered alarm definitions,
  84   then (step 8) it will fire the alarm to the "consumer" who owns the
  85   instance
  86
  87 * Consumer(VNFM): (step 9) receives the event and (step 10) recreates a new
  88   instance
  89
  90 Test case
  91 """""""""
  92
  93 Functest will call the "run.sh" script in Doctor to run the test job.
  94
  95 Currently, only 'Apex' and 'local' installer are supported. The test also
  96 can run successfully in 'fuel' installer with the modification of some
  97 configurations of OpenStack in the script. But still need 'fuel' installer
  98 to support these configurations.
  99
 100 The "run.sh" script will execute the following steps.
 101
 102 Firstly, get the installer ip according to the installer type. Then ssh to
 103 the installer node to get the private key for accessing to the cloud. As
 104 'fuel' installer, ssh to the controller node to modify nova and ceilometer
 105 configurations.
 106
 107 Secondly, prepare image for booting VM, then create a test project and test
 108 user (both default to doctor) for the Doctor tests.
 109
 110 Thirdly, boot a VM under the doctor project and check the VM status to verify
 111 that the VM is launched completely. Then get the compute host info where the VM
 112 is launched to verify connectivity to the target compute host. Get the consumer
 113 ip according to the route to compute ip and create an alarm event in Ceilometer
 114 using the consumer ip.
 115
 116 Fourthly, the Doctor components are started, and, based on the above preparation,
 117 a failure is injected to the system, i.e. the network of compute host is
 118 disabled for 3 minutes. To ensure the host is down, the status of the host
 119 will be checked.
 120
 121 Finally, the notification time, i.e. the time between the execution of step 2
 122 (Monitor detects failure) and step 9 (Consumer receives failure notification)
 123 is calculated.
 124
 125 According to the Doctor requirements, the Doctor test is successful if the
 126 notification time is below 1 second.