Mode de fonctionnement

Concept et Terminologie

L'architecture de NMS a été conçue de façon à offrir une solution de surveillance et de pilotage très opérationnelle du niveau de qualité de service, et ce d'un bout à l'autre de la chaîne de services.

Parmi ses principes architecturaux de base, on retiendra que NMS a été conçu de façon à :

  • Impacter au minimum les ressources systèmes - CPU, disque, mémoire -
  • Traiter intelligemment les messages, pour éviter un trafic réseau inutile - ex par la suppression de messages redondants -
  • Garantir la délivrance des messages à 100% - sans perte de messages comme sur un réseau utilisant uniquement le protocole SNMP
  • Communiquer au travers des firewalls
  • Se déployer facilement, générant un " payback " et un retour sur investissement (RSI) rapide avec un 'TCO' minime
  • Respecter les investissements déjà réalisés, en s'appuyant sur les solutions de supervision déjà en place et en intégrant les solutions 'maison'
  • Évoluer en fonction des nouveaux besoins de pilotage des Services
  • Pouvoir personnaliser, et distribuer de façon simplifiée des sondes spécifiques au travers des ateliers de développement intégrés.

Les grandes fonctions couvertes en standard par NMS sont les suivantes :

1. Gestion des événements en général et des alarmes en particulier, au titre de la supervision technique
2. Gestion des tableaux de bords de performances temps réels et historisés.
3. Gestion de la qualité, des niveaux, des engagements, et de la qualité de services en général (web ou autre).

Les rapports permettront de rapprocher et d'analyser la qualité de service mesurée au regard des engagements pris auprès des clients internes. Les tableaux de bord adressent un spectre depuis la vision technique jusqu'à la vision managériale ; ils sont destinés aux administrateurs de la solution autant qu'aux utilisateurs.

L'architecture de Qualité de Service de NMS repose sur le principe de hiérarchie de l'infrastructure IT depuis la notion de 'Domaine' jusqu'au plus fin niveau de granularité représenté par la 'Sonde' NMS.
Le 'Domaine' définit le périmètre de l'ensemble des ressources de l'infrastructure IT pour lequel les indicateurs de Qualité de Service sont calculés.

Ces domaines sont eux-mêmes structurés en sous groupes appelés 'Hub'.
Un Hub prend en charge un ensemble de 'Robots' chargé du management d'une ressource IT. Ces Robots peuvent être regroupés sur des critères divers aussi bien fonctionnels, que géographiques, techniques ou autres.

Un Robot pilote une ou plusieurs Sondes, dont le rôle intrinsèque est de :

  • Surveiller en local toute ou partie de la ressource selon le périmètre fonctionnel de la Sonde (des alarmes techniques sont dans ce cas générées en cas de besoin),
  • Collecter les éléments de Qualité de Service.

NMS dispose d'une importante bibliothèque de Sondes. Ces 'agents' sont déployés en fonction des besoins de l'infrastructure du client pour générer et gérer l'information technique et de qualité de service nécessaire. 
 

Collecte des informations

NMS a été conçu dès l'origine pour être très peu intrusif et propose à ce titre deux approches possibles de la supervision : avec ou sans agent


1) Avec Agent
Les agents (appelés sondes) sont installés sur les serveurs en fonction des ressources à superviser, et remontent leurs informations via un robot vers le hub dont ils dépendent. Ces sondes sont très faiblement consommatrices de ressources dans tous les cas.
La taille des robots n'excède pas 10 Mo de Ram et une consommation de CPU inférieure à 1%. L'ensemble des paramètres de performance est réglable de façon spécifique pour chaque serveur ou selon une stratégie de groupe.

2) Sans Agent (agentless)
Il est aussi possible d'installer  un agent sur un serveur unique qui évitera l'ouverture de ports TCP/UDP, ou une consommation de bande passante excessive. Celui-ci sera alors capable d'aller chercher les informations à distance par le biais des services WMI, SNMP ou SSH par exemple.

Exemple, la sonde " rsp " va permettre de remonter les informations concernant l'utilisation processeur & mémoire, l'espace disque, les services & processus ainsi que sur le journal d'événements.

 

Il est à noter qu'en cas de panne réseau, les informations sont automatiquement 'spoolées' (mises en file d'attente) afin de permettre leur restitution lors du retour à la normal.

Les consommations de ressources (CPU, disque, mémoire, bande passante..) sont proportionnelles à la granularité des informations remontées (le nombre de seuils d'alertes par machine, le nombre d'éléments participants à l'architecture de qualité de service…).

Les couches basses de NMS fonctionnent en full TCP. Cette technologie permet de garantir la réception des informations collectées.

Il est bien rare que les réseaux clients soient impactés par le déploiement et la mise en œuvre de NMS.

Le fonctionnement de NMS repose sur les différents niveaux d'échanges de l'information.

Collecte des données
Effectuée par les Sondes NMS ou autres 'sources' d'informations

Analyse des données et automatisation
Effectuée par les Robots NMS, quelle que soit la Sonde (NMS ou autre)

Transport des données
Pris en charge par le Middleware 'NMS Message Bus', sécurisé et dédié au transport des informations de qualité de service et aux alarmes

Analyse et stockage des données
Effectuée par la fonction SLM Server et Alarm Server

Gestion des Alarmes et des niveaux de Service
Effectuée par les composants graphiques de NMS (Manager Console, SLM Console, Enterprise Console)

 

Stockage des données

NMS stocke l'ensemble des données collectées dans des bases de données standard (dont le Modèle ouvert, laisse l'accès au schéma).

Ce mode de stockage facilite la sécurisation de NMS et l'exploitation des données stockées ainsi que leurs sauvegardes.

Les informations de type Qualité de service (QoS) sont enregistrées dans une base de données SQL Server, dont le schéma est le suivant:

 

Les alarmes sont quant à elles stockées par défaut dans une base SQL Lite mais peuvent si besoin être aussi enregistrées dans une base SQL Server.

La structure de la table des alarmes dans SQL Lite est la suivante :