Forum Français

Reply
Highlighted

ArubaOS-CX et l'automatisation - Part 3 : Présentation du Network Analytics Engine

Le Network Analytics Engine (NAE) est un framework dont l’objectif est de pouvoir mettre en place un outil simple de Root Cause Analysis et d'actions au sein de l’équipement.

 

En utilisant les capacités d’automatisation, de programmabilité et de visibilité d’ArubaOS-CX, cet outil unique sur le marché intégré nativement à l’OS, permet d’avoir la faculté de monitorer, troubleshooter, collecter des données réseaux, et eventuellement prendre des actions sur lui-même ou sur son environnement, au travers de simple agents installés sur l’OS.

Screen Shot 2018-12-17 at 12.30.31.png

 

 

Network Analytics Engine intéragit en temps-réel avec la System State Database (SSDB) , permettant ainsi de pouvoir créer des modules logiciels (agents NAE).

 

1. Principes de fonctionnement

 

Le principe de fonctionnement de Network Analytics Engine est donc le suivant :

 

L’administrateur importe des scripts qui comportent plusieurs éléments :

  • Les ressources qu’il souhaite monitorer au sein de l’équipement, que ce soit matériel ou logiciel (Monitor)
  • Les règles de monitoring (Rules)
  • Les seuils ou évènements à partir desquels des actions doivent être prises si ces derniers sont dépassés (Conditions)
  • Les actions qui seront prises (Actions)

Une fois les scripts importés, des agents peuvent être créés.Ce sont des instanciations des scripts et qui seront alors les instances de monitoring - Une interface Web de consultation est automatiquement créée par ArubaOS-CX lorsqu’un nouvel agent est créé.

L’agent monitore alors en temps réel la ou les ressources contenues dans son script source.

Screen Shot 2018-12-17 at 10.55.11.png

 

En cas de déclenchement alors l’agent prend automatiquement les actions qui sont également indiquées dans son script source. Parmi ces actions 

  • Création d’une alerte spécifique
  • Modification éventuelle du niveau de criticité d’une alerte créée
  • Passage d’une ou plusieurs lignes de commandes, afin d’avoir une visibilité rapide sur certaines lignes de commandes de troubleshooting, ou de faire une modification de configuration. Ces actions peuvent etre realisées aussi bien sur ArubaOS-CX que sur l'OS sous-jacent (Bash).
  • Création d’une page Web, afin de présenter des résultats ou informations de manière extrêmement personnalisée
  • Toute action possible au travers des modules Python intégrés – Cela comprend notamment la possibilité de pouvoir interagir avec l’environnement de l'equipement, au travers de sessions SSH ou de requêtes API.
  • Generation d'un Syslog personnalisé.
  • Lorsque l'état revient à la normal, des actions de retour arrière, parmi celles mentionnées ci-dessus, peuvent être réalisées automatiquement par l’agent, afin de rétablir un niveau d’alerte normal et de rendre la solution, que ce soit interne ou externe, dans un mode de fonctionnement habituel.

Screen Shot 2018-12-17 at 12.27.46.png

 

Lorsque le seuil revient à la normal, des actions de retour arrière, parmi celles mentionnées ci-dessus, peuvent être réalisées automatiquement par l’agent, afin de rétablir un niveau d’alerte normal et de rendre la solution, que ce soit interne ou externe, dans un mode de fonctionnement habituel.

 

De manière à être consultables dans le temps, l'ensemble des valeurs récuperées, ainsi que les incidents et éléments liés, sont conservées dans une base de données temporelle, appelée Time Series Database.

 

La version 10.1 d’ArubaOS-CX a amené de nombreuses améliorations au Network Analytics Engine :

  • Baselining : Une fonction de détermination automatique des seuils (baselining) a été apportée, de manière à permettre au Network Analytics Engine de déterminer tout seul quels sont les seuils pouvant déclencher une alerte. En effet, parce qu’il peut être compliqué de savoir quel est le comportement normal d’un équipement, notamment les valeurs de seuils, ou parce que ces valeurs peuvent être différentes d’un client à l’autre, d’un type d’équipement a l’autre, ou d’un contexte d’utilisation a l’autres, alors il est désormais possible de demander à NAE de les determiner de manière autonome, après une phase d’apprentissage.
  • Analytics Data Collections : Cette fonctionnalité permet au Network Analytics Engine de monitorer les trafics entrants et sortants à destination ou en provenance de ressources spécifiées. Ceci permet alors aux administrateurs de monitorer des statistiques agrégées, basé sur des caractéristiques de paquets. La fonction ADC est construite de manière similaire a une ACL, mais ne fait que monitorer le trafic correspondant à cette ACL. C’est notamment cette fonction qui est prise en compte pour l’agent surveillant le trafic Office 365.
  • « Cross-Platforms » : Grâce au support de VSX, et notamment grâce a l’intégration du mot-clé « vsx-peer » dans les URI, un même agent peut désormais surveiller les ressources sur l’équipement local, mais également sur son peer VSX.
  • Graphiques multiples : Il est désormais possible d’avoir plusieurs graphiques pour un même agent.

2. Les sandboxes

 

Une des particularité du mode de fonctionnement du Network Analytics Engine est la notion de Sandbox.

En effet, lorsque les agents doivent exécuter des fonctions Python contenues dans les actions, ArubaOS-CX monte une sandbox, qui est une sorte de container, dans laquelle les scripts sont executés. Cette sandbox est supprimée lorsque l'action est terminée.

Cela permet alors d'avoir un environnement contrôlé, avec des droits d'accès et des ressources spécifiques.

 

Cela permet alors de pouvoir bénéficier des avantages suivants :

  • Plusieurs agents peuvent fonctionner en parallèle sans que l'un d'eux ne vampirise les ressources des autres ou de l'équipement, puisque chaque environnement aura ses propres ressources, et ne pourra pas les dépasser
  • Les agents bénéficient alors des mécanismes de haute-disponibilité d'ArubaOS-CX, notamment la capacité donnée à une démon de reprendre son état après une defaillance sur l'équipement, sans qu'il ait a tout recommencer.
  • Le fait que les sandbox soient des environnements controlés permet de limiter l'accès des agents aux informations sensibles contenues sur l'equipement, comme les certificats.

3. Utilisation

 

Les scripts utilisés peuvent être :

  • Utilisés parmi ceux pré-chargés sur ArubaOS-CX
  • Développés directement par l’entité administratrice de l’équipement, grâce notamment à l’utilisation des guides de configuration Network Analytics Engine, mais également à la communauté Aruba Airhead, afin de répondre à un besoin extrêmement spécifique.
  • Téléchargés à partir de la platerforme Github, sur laquelle un espace partagé (« Repo ») et en libre accès dédié au Network Analytics Engine est présent, avec des scripts mis à disposition et téléchargeables facilement. Il est donc possible de bénéficier de l’expérience d’autres utilisateurs, et ainsi de pouvoir utiliser leurs scripts si ces derniers répondent à un besoin.
  • Téléchargés directement via la plateforme Aruba Solution Exchange (ASE). Il est à noter qu’un lien direct existe entre l’interface Web d’ArubaOS-CX et la platforme ASE, de manière à faciliter encore plus l’intégration de nouveaux scripts. En effet, la liste des scripts disponibles sur ASE peut s’affiche directement sur l’interface, et il suffit de les télécharger pour les installer. A ce jour, une cinquantaine de scripts sont disponibles.

Screen Shot 2018-12-17 at 12.26.50.png

 

4. L'Interface Web

L’interface Web du Network Analytics Engine, qui est joignable au travers de celle d’ArubaOS-CX, est décomposée est 3 parties distinctes :

  • Le dashboard principal - Cette page, qui est la page principal du Network Analytics Engine, permet d’avoir une visibilité globale et rapide sur l’ensemble des agents et scripts utilisés au sein d’ArubaOS-CX, mais également les valeurs retournées par les monitorings et l’état des agents.Screen Shot 2018-12-17 at 10.59.24.png

     

  • La gestion des scripts et agents – Cette page permet de pouvoir intégrer ou supprimer des scripts ainsi que des agents sur le système
  • Le dashboard d’un agent – Ce Dashboard est généré automatiquement à la création d’un agent. Il n’y a donc aucune action manuelle à réaliser. Il permet de voir très rapidement et très simplement les différentes valeurs retournées par le monitoring, mais également les éventuelles alertes retournées par de dernier.Screen Shot 2018-12-17 at 11.00.29.png

     

En cliquant sur chacune des alertes, alors il est possible de voir la raison pour laquelle l’alerte a été générée, mais également les actions qui ont été prises.

 

Screen Shot 2018-12-17 at 11.05.10.png

 

Comme évoqué précédemment, il est également possible d'avoir un accès direct à Aruba Solution Exchange via l'interface de l'équipement, et à son catalogue de scripts publiés, permettant ainsi de pouvoir télécharger/installer directement celui souhaité.

Screen Shot 2018-12-17 at 11.10.51.png

 

5. Cas d'usage

 

Comme évoqué, le Network Analytics Engine est une fonctionnalité de pouvoir monitorer en temps réel différentes informations présentes dans ArubaOS-CX, et de pouvoir réaliser de manière autonomes différentes actions en fonction de critères qui sont prédéfinies dans les agents.

Partant de ce constat, il est donc possible d’imaginer différents cas d’utilisation de ce moteur d’analyse, et les avantages que l’administrateur peut en tirer :

 

1. Problème de DHCP défaillant

Il est désormais possible avec le Network Analytics Engine de superviser le service DHCP en comparant le nombre de requêtes DHCP avec le nombre de réponses DHCP.

SI ce ratio est anormal, sur une période prédéterminée, alors l’action suivante est prise automatiquement par ArubaOS-CX :

  • Affichage de la configuration DHCP de l’équipement
  • Ping du serveur DHCP externe afin de vérifier qu’il est toujours joignable
  • Prise en main à distance sur le serveur DHCP par ArubaOS-CX, afin de redémarrer si nécessaire le service DHCP
  • Création d’une alerte personnalisée afin de donner les bonnes informations à l’administrateur.

2. Supervision du routage

Il est possible avec Network Analytics Engine de superviser le nombre de routes disponibles sur l’équipement, de les classer par méthodes d’apprentissage (statique, dynamiques), de vérifier si des phénomènes de flapping existent, notamment sur les adjacences en cas d’utilisation de protocoles de routage dynamique.

 

3. Problème lié à la température de l’équipement

Il est également possible de surveiller la température de l’équipement. Une alerte peut alors être générée automatiquement en cas de dépassement d’un certain seuil.

 

4. Intégration avec des solutions tierces :

  • Interaction avec des switchs d’accès ArubaOS-Switch. Cela peut par exemple permettre, en fonction d’un évènement détecté par NAE, de collecter de l’information sur un switch d’accès via les API, voire de déclencher une action comme le redémarrage d’un equipement PoE.
  • Interaction avec Airwave, de manière à intégrer un nouvel equipement dans le bon groupe Airwave
  • Interaction avec ClearPass. Cela peut permettre par exemple, en monitorant les ACL hits, de récupérer de l’information spécifique ou de réaliser un CoA sur un ce même endpoint
  • Interaction avec ServiceNow. Cela peut permettre d’ouvrir un ticket dans ServiceNow lorsqu’un change a été réalisé sur l’equipement
  • Etc…

6. Ressources

 

Vous pourrez trouver des informations complementaires sur les liens suivants :

- Une video de présentation de NAE par Alvin Casto, sur Aruba Broadcasting Channel

- Airheads 

- Groupe Developper Community

- Technical Whitepaper sur Arubapedia for Partners.

New Contributor

Re: ArubaOS-CX et l'automatisation - Part 3 : Présentation du Network Analytics Engine

do you have the link for an english version? thanks!


Re: ArubaOS-CX et l'automatisation - Part 3 : Présentation du Network Analytics Engine

Hi Daniel,

 

Unfortunately not.

I'll translate it as soon as possible, and keep you in touch.

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: