| PrakashH | 3bcb00f | 2019-01-22 08:19:43 +0000 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License.
|
| 2 | .. http://creativecommons.org/licenses/by/4.0
|
| 3 |
|
| PrakashH | 3bcb00f | 2019-01-22 08:19:43 +0000 | [diff] [blame] | 4 | Design
|
| 5 | ======
|
| 6 |
|
| 7 | There are 4 processes created as below
|
| 8 |
|
| 9 | Main process
|
| 10 | ------------
|
| 11 |
|
| 12 | This is the initial process which does the following.
|
| 13 |
|
| 14 | - Download CBS configuration and update the vnf_table_1
|
| 15 | - Spawns HB worker process, DB Monitoring process and CBS polling
|
| 16 | process (if required)
|
| 17 | - Periodically update the hb_common table
|
| 18 |
|
| 19 | HB worker process
|
| 20 | -----------------
|
| 21 |
|
| 22 | This process is created by main process and does the following.
|
| 23 |
|
| 24 | - It waits on the HB Json event message from DMaaP message router
|
| 25 | - It receives the HB Json message and retrieves sourceName,
|
| 26 | lastEpochTime, eventName in the incoming message
|
| 27 | - It checks for the received eventName against the eventName in
|
| 28 | vnf_table_1. If eventName is not matched, then it discards the
|
| 29 | message.
|
| 30 | - It checks for the received sourceName in the vnf_table_2. If the
|
| 31 | sourceName is already there in vnf_table_2, then it updates the
|
| 32 | received HB Json message in vnf_table_2 against that sourceName. If
|
| 33 | the sourceName is not there in vnf_table_2, then it adds an entry in
|
| 34 | vnf_table_2 for that eventName and increments the sourceName count in
|
| 35 | vnf_table_1
|
| 36 |
|
| 37 | DB Monitoring process
|
| 38 | ---------------------
|
| 39 |
|
| 40 | This process is created by main process and does the following.
|
| 41 |
|
| 42 | - The DB monitoring process scans through each entry of vnf_table_1 and
|
| 43 | looks at the corresponding vnf_table_2 and checks the condition for
|
| 44 | Control Loop event is met or not
|
| 45 | - If it finds that the multiple consecutive HB are missed, it raises
|
| 46 | the Control Loop event.
|
| 47 | - It also clears the control loop event by looking at recently received
|
| 48 | HB message.
|
| 49 | - Because of reconfiguration procedure, some of the existing entries in
|
| 50 | vnf_table_1 may become invalid. DB Monitoring process would clean the
|
| 51 | DB by looking at validity flag maintained in each vnf_table_1 table
|
| 52 | entry. If not valid, it removes the entry in vnf_table_1 and also
|
| 53 | removes the corresponding entries of vnf_table_2.
|
| 54 |
|
| 55 | CBS polling process
|
| 56 | -------------------
|
| 57 |
|
| 58 | If the local configuration file (config/hbproperties.yaml) indicates
|
| 59 | that CBS polling is required, then main process would create the CBS
|
| 60 | polling process. It does the following.
|
| 61 |
|
| 62 | - It takes the CBS polling interval from the configuration file.
|
| 63 |
|
| 64 | - For every CBS polling interval, it sets the hb_common with state as
|
| 65 | reconfiguration to indicate the main process to download CBS
|
| 66 | configuration
|
| 67 |
|
| 68 | CBS configuration download support
|
| 69 | ----------------------------------
|
| 70 |
|
| 71 | Apart from the above, a function/method is provided to Docker container
|
| 72 | that would download the CBS configuration whenever the configuration
|
| 73 | changes. This method/function would read hb_common state and change the
|
| 74 | state to reconfiguration.
|
| 75 |
|
| 76 | Heartbeat Microserice Multi instance support
|
| 77 | --------------------------------------------
|
| 78 |
|
| 79 | In order to work smoothly in an environment having multiple HB micro
|
| 80 | services instances, processes would work differently as mentioned below.
|
| 81 |
|
| 82 | **Main Process:**
|
| 83 |
|
| 84 | Active Instance:
|
| 85 | - Download CBS configuration and process it
|
| 86 | - Spawns processes
|
| 87 | - Periodically update hb_common with last accessed time to indicate that active instance is Alive.
|
| 88 |
|
| 89 | Inactive Instance:
|
| 90 | - Spawns processes
|
| 91 | - Constantly check hb_common entry for last accessed time
|
| 92 | - If the last accessed time is more than a minute or so, then it assumes the role of active instance
|
| 93 |
|
| 94 | **HB worker process:** Both active and inactive instance behaves the sames as metnioned in the Design section.
|
| 95 |
|
| 96 | **DB Monitoring process:** Both active periodically checks its process ID/hostname with hb_common data to know whether it is an active instance or not. If inactive instance it does nothing. If active instance, it behaves as mentioned in design section.
|
| 97 |
|
| 98 | **CBS Polling process:** Periodically checks its process ID/hostname with hb_common data to know whether it is an active instance or not. If inactive instance it does nothing. If active instance, it behaves as mentioned in design section.
|
| 99 |
|
| 100 | Handling of some of the failure scenarios
|
| 101 | -----------------------------------------
|
| 102 |
|
| 103 | Failure to download the configuration from CBS – In this case, local
|
| 104 | configuration file etc/config.json is considered as the configuration
|
| 105 | file and vnf_table_1 is updated accordingly.
|
| 106 |
|
| 107 | The Reconfiguration procedure is as below
|
| 108 | -----------------------------------------
|
| 109 |
|
| 110 | - If the state is Reconfiguration, then HB worker process, DB
|
| 111 | monitoring process and CBS polling process would wait for
|
| 112 | reconfiguration to complete.
|
| 113 | - Set each entry as invalid by using validity flag in vnf_table_1
|
| 114 | - Download the json file from CBS.
|
| 115 | - Set the validity flag to indicate to valid when an entry is updated.
|
| 116 |
|
| 117 | Postgres Database
|
| 118 | -----------------
|
| 119 |
|
| 120 | There are 3 tables maintained.
|
| 121 |
|
| 122 | **Vnf_table_1 table:**
|
| 123 | This is table is indexed by eventName. Each entry
|
| 124 | has following parameters in it.
|
| 125 |
|
| 126 | - eventName
|
| 127 | - Configured heartbeat Missed Count
|
| 128 | - Configured Heartbeat Interval
|
| 129 | - Number of SourceName having same eventName
|
| 130 | - Validity flag that indicates VNF entry is valid or not
|
| 131 | - It also has following parameter related to Control loop event
|
| 132 | - policyVersion
|
| 133 | - policyName
|
| 134 | - policyScope
|
| 135 | - target_type
|
| 136 | - target
|
| 137 | - closedLoopControlName
|
| 138 | - version
|
| 139 |
|
| 140 | **Vnf_table_2 table:**
|
| 141 | For each sourceName there would be an entry in vnf_table_2.
|
| 142 | This is indexed by eventName and SourceName. Each entry has
|
| 143 | below parameters
|
| 144 |
|
| 145 | - SourceName
|
| 146 | - Last received heartbeat epoch time
|
| 147 | - Control loop event raised flag. 0 indicates not raised, 1 indicates
|
| 148 | CL event raised
|
| 149 |
|
| 150 | **hb_common table:**
|
| 151 | This is a single entry table.
|
| 152 |
|
| 153 | - The configuration status which would have one of the below.
|
| 154 | - **RECONFIGURATION** – indicates CBS configuration processing is in
|
| 155 | progress.
|
| 156 | - **RUNNING** – CBS configuration is completed and ready to process HB
|
| 157 | event and send CL event.
|
| 158 | - The process ID – This indicates the main process ID of the active HB
|
| 159 | instance which is responsible to take care of reconfiguration
|
| 160 | - The source Name – It has 2 parts, hostname and service name. The
|
| 161 | hostname is the Docker container ID. The service name is the
|
| 162 | environment variable set for SERVICE_NAME
|
| 163 | - The last accessed time – The time last accessed by the main process
|
| 164 | having the above process ID.
|