Autonomous Link Maintenance (ALM) Plugin
The primary objective of the Autonomous Link Maintenance (ALM) plugin is to enhance cluster availability and improve the rate of job completion. This objective is accomplished by utilizing machine learning (ML) models to predict potential link failures. The plugin then isolates the expected failing links, implements maintenance procedures on them, and subsequently restores the fixed links to their original state by removing the isolation.
The ALM plugin performs the following tasks:
Collects telemetry data from UFM and employs ML jobs to predict which ports need to be isolated/de-isolated
Identifies potential link failures and isolates them to avert any interruption to traffic flow
Maintains a record of maintenance procedures that can be executed to restore an isolated link
After performing the required maintenance, the system verifies if the links can be de-isolated and restored to operational status (brought back online)
The ALM plugin operates in the following two distinct modes:
Shadow mode
Collects telemetry data, runs ML prediction jobs, and saves the predictions to files.
Active mode
Collects telemetry data, runs ML prediction jobs, and saves the predictions to files.
Automatically isolates and de-isolates based on predictions.
It is essential to note that a subset of the links must be specified in the allow list to enable this functionality.
The Autonomous Link Maintenance (ALM) plugin can be deployed using the following methods:
On the UFM Appliance
On the UFM Software
To deploy the plugin, follow these steps:
Download the ufm-plugin-alm-image from the NVIDIA License Portal (NLP).
Load the downloaded image onto the UFM server. This can be done either by using the UFM GUI by navigating to the Settings -> Plugins Management tab or by loading the image via the following instructions:
Log in to the UFM server terminal.
Run:
docker load -I <path_to_image>
After successfully loading the plugin image, the plugin should become visible within the plugins management table within the UFM GUI. To initiate the plugin’s execution, simply right-click on the respective in the table.
The ALM plugin collects data from the UFM Enterprise appliance in the following two methods:
Low-frequency collection: This process occurs every 0 minutes and gathers data for the following counter: hist0, hist1, hist2, hist3, hist4, phy_effective_errors, phy_symbol_errors
High-frequency collection : This process occurs every 10 seconds and gathers data for the following counters: phy_state,logical_state,link_speed_active,link_width_active,fec_mode_active, raw_ber,eff_ber,symbol_ber,phy_raw_errors_lane0,phy_raw_errors_lane1,phy_raw_errors_lane2, phy_raw_errors_lane3,phy_effective_errors,phy_symbol_errors,time_since_last_clear, hist0,hist1,hist2,hist3,hist4,switch_temperature,CableInfo.temperature,link_down_events, plr_rcv_codes,plr_rcv_code_err,plr_rcv_uncorrectable_code,plr_xmit_codes,plr_xmit_retry_codes, plr_xmit_retry_events,plr_sync_events,hi_retransmission_rate,fast_link_up_status, time_to_link_up,status_opcode,status_message,down_blame,local_reason_opcode, remote_reason_opcode,e2e_reason_opcode,num_of_ber_alarams,PortRcvRemotePhysicalErrorsExtended, PortRcvErrorsExtended,PortXmitDiscardsExtended,PortRcvSwitchRelayErrorsExtended,PortRcvConstraintErrorsExtended, VL15DroppedExtended,PortXmitWaitExtended,PortXmitDataExtended,PortRcvDataExtended,PortXmitPktsExtended, PortRcvPktsExtended,PortUniCastXmitPktsExtended,PortUniCastRcvPktsExtended,PortMultiCastXmitPktsExtended,PortMultiCastRcvPktsExtended
The collected counters can be configurable and customized to suit your requirements. The counters can be found at /opt/ufm/conf/plugins/alm/counters.cfg
The ALM configuration is used for controlling isolation/de-isolation. The configuration can be found under /opt/ufm/cyber-ai/conf/cyberai.cfg.
Name |
Section name |
Description |
mode |
CyberAi |
The mode can be active or shadow The active mode means the alm will apply isolation/deisolation rule omn all ports exceptin the port in the expect list And the shadow mode mean the alm will apply isolation/deisolation rules on the ports on the except list The mode can be either "active" or "shadow." In active mode, the ALM will enforce isolation/deisolation rules on all ports except those listed in the "expect" list. In shadow mode, the ALM will enforce isolation/deisolation rules on the ports listed in the "except" list. |
except_list |
CyberAi |
Includes the ports that receive the opposite treatment compared to the mode. Format: portguid_number, portguid_portnumber2 |
max_per_hour |
Isolation |
The maximum number of ports that can be isolated in a hour |
max_per_week |
Isolation |
Maximum number of ports that can be isolated in a week |
max_per_month |
Isolation |
Maximum number of the ports that can be isolated in a month |
Deisolation_time |
DeIsolation |
The waiting time before deisolate the isolated port |
max_per_hour |
DeIsolation |
The maximum number of deisolated port per hour |
absolute_threshold_of_isolated_ports |
Isolation |
The maximum number of ports than can be isolated in one sample |
The table presented below displays the names and descriptions of ALM jobs. These jobs are designed to predict the ports that require isolation/de-isolation. Upon enabling the ALM plugin, these ALM jobs run periodically.
ALM Job Name |
Description |
Frequency |
Port_hist |
By using the low frequency bit error histogram counters, the ALM job identifies the ports that will be monitored at high frequency in the next time interval. The job generates an output file that is later read by the high frequency telemetry monitoring job. It prioritizes links that are more susceptible to failure. |
600 seconds |
Low_freq_predict |
Predicts the likelihood of a port failure by analyzing input data from low frequency telemetry, while only utilizing physical layer counters. The prediction works for isolated ports as well. The resulting output from this task serves as a critical input for determining whether to isolate or de-isolate ports. |
10 seconds |