Failure Prediction using AI/ML in NFV Environments

Anuket Project

Failure Prediction using AI/ML in NFV Environments

 

Data

 

 

Failure Type

Failure parameter

  Failure Event

 Infrastructure Metrics

Comments

Failure Type

Failure parameter

  Failure Event

 Infrastructure Metrics

Comments

Links

Link Down.

Link removed

Virtual Switch link failure

Hardware Failure

Interface Down

dhcp-agent.log

neutron-dhcp-agent

l3-agent.log

neutron-l3-agent

linuxbridge-agent.log

neutron-linuxbridge-agent

openvswitch-agent.log

neutron-openvswitch-agent

(Ref: https://docs.openstack.org/ocata/config-reference/networking/logs.html)

Network interface status, 

High packet drop,

low throughput,

excessive latency or jitter

 

crc-statistics, fabric-link-failure, link-flap, transceiver-power-low

 

VM

Deployment/Start Failures:

  1. Failed to start*

  2. Failed to boot*

Post-Deployment/Start failures:

  1. Shutdown

  2. Crash

  3. Hang*

  4. Panic

nova-compute.log

nova-api.log

nova-scheduler.log

libvirt.log

qemu/$vm.log

neutron-server.log

glance/cinder - 

flavor

Node and Core-mapping

 

cpu: per-core utilization

memory

Interfaces statistics - sent, recv, drops

Disk Read/Write

 

If possible, Infrastructure metrics and syslogs from within the VM should be collected.

Deployment/Start failures can be the first step.

 

Container

Deployment/Start Failures:

  1. Failed to start*

  2. Failed to boot*

Post-Deployment/Start failures:

  1. Shutdown

  2. Crash

  3. Hang

  4. Panic

  • OS layer – syslog, boot.log, kern.log etc.

  • Kubernetes Layer – container Logs (/var/log/containers)

  • OpenStack Layer – OpenStack service Logs

 

cpu: per-core utilization

memory

Interfaces statistics - sent, recv, drops

Disk Read/Write

 

Node

A node failure (hardware failure, OS crash, etc)

A) node network connectivity failure

B) nova service failure

C) Failure of other OpenStack services

/var/log/nova/nova-compute.log
(To ensure that it has successfully connected to the AMQP server
Ref: https://docs.openstack.org/operations-guide/ops-maintenance-compute.html)

 

Cloud controller

nova-*

/var/log/nova

Cloud controller

glance-*

/var/log/glance

Cloud controller

cinder-*

/var/log/cinder

Cloud controller

keystone-*

/var/log/keystone

Cloud controller

neutron-*

/var/log/neutron

Cloud controller

horizon

/var/log/apache2/

All nodes

misc (swift, dnsmasq)

/var/log/syslog

Compute nodes

libvirt

/var/log/libvirt/libvirtd.log

Compute nodes

Console (boot up messages) for VM instances:

/var/lib/nova/instances/instance-<instance id>/console.log

Block Storage nodes

cinder-volume

/var/log/cinder/cinder-volume.log

(Ref: https://docs.openstack.org/operations-guide/ops-logging.html)

A) node network connectivity failure

  1. management network

  2. VMs communication network

  3. storage network

B) nova service failure (e.g., process crashed) -- detected and restarted by a local watchdog process

  1. compute

  2. volume

  3. network

  4. scheduler

  5. api.

C) Failure of other OpenStack services -- N/A, assuming redundant/highly available configuration

  1. Glance

  2. Keystone

 

Interfaces statistics - sent, recv, drops

 

Hypervisor Metrics, Nova Server Metrics, Tenant Metrics, Message Queue Metrics

 

 

 

Keystone  and Glance Metrics

 

 

 

 

Application

Crash/Connectivity/Non-Functional

Application Log i.e. If it is Apache then logs of Apache

(/var/log/apache2)

Packet Drops, Latency, Throughput, Saturation, Resource Usage

Deploy Collectd within the application and collect both application logs and infrastructure metrics

Middleware Services

 

 

 

 

Models

We have taken three types of models and in those models we have considered Failure Prediction problem and the remaining types are given as:
 

  1. Event Correlation

  2. Anomaly Detection

  3. Failure Prediction

We are focusing on Failure Prediction of Node, Application, VM, Service, Container and Links. Our aim is to predict the failures before they happen so that user can take necessary actions regarding those failures. So, to implement Failure Prediction models we are developing our models using Classical Neural Networks techniques i.e. RNN & LSTM. 

Gaps

From the perspective of Telco after doing a literature survey we found most of the work has done on VM and Applications. There are less work has done for Node Failures, Link Failures, Middleware Services and also there is a lack of Publicly available datasets for these failures. Majority of researchers have used ARIMA & RNN so to improve the performance of the prediction model we can do some experiments with Generative Adversarial Networks (GAN), Graphical Neural Network (GNN). Also, in our literature survey we found that majority of the publicly available data does not contain time stamp. So to make the future predictions we will need of Time Series data. 

 

Enhancements