White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue


Page 81 of 144

Understanding OPNFV 81 ● Marking the status of affected resources appropriately ● Generating alarms to a higher-level fault management system OPNFV Doctor may also be used with the OpenStack Vitrage root-cause-analysis project. The combined OPNFV Doctor and OpenStack Vitrage solution involves the following steps: Fault Management Event Flow (Doctor + Vitrage) Monitor The first step, of course, is to monitor a failure in the infrastructure. Doctor allows for many different options here, including c oll ect d (see OPNFV Barometer). The raw failure information is transmitted to the failure policy engine. Failure Policy Engine A raw failure does not imply that the failure has to be dealt with by the MANO layer. For example, if there are two redundant NICs and one fails, an operator may choose to not consider it a failure. Of course, the NIC has to be replaced, but that's a different topic. Or take an example where memory utilization reaches 80%. Some operators may consider that a failure that needs to be dealt with. Others may not. For this reason, a policy engine is needed to determine if the raw failure is indeed a failure from the MANO layer's point of view or not. OpenStack Congress, a policy-as-a-service project accomplishes this by enabling the user to create policies.

Articles in this issue

view archives of White Papers - Understanding OPNFV