Parallèlement, le volume des configurations, des journaux et des événements d’alarme augmente, et les liens entre les composants se complexifient. En conséquence, les ingénieurs passent plus de temps à collecter des données provenant de différentes interfaces et nœuds qu’au diagnostic lui-même.
Il en résulte le besoin d’un système de gestion unifié qui regroupe le travail avec les éléments réseau, les configurations, les alarmes et les statistiques d’exploitation.
Qu’est-ce que Stingray NMS
Stingray NMS est le système de gestion de la plateforme Stingray. Il regroupe la configuration, la supervision, la collecte de statistiques, le traitement des alarmes et l’audit des actions sur tous les produits de VAS Experts.
Stingray NMS est fourni sous forme de solution virtualisée et s’intègre dans l’infrastructure existante de l’opérateur sans dépendance stricte à une plateforme matérielle.
Architecture de Stingray NMS
Déploiement et infrastructure
Le système est déployé dans le cluster de virtualisation du client, dans une infrastructure TelcoCloud dédiée ou sur des serveurs distincts alloués aux fonctions réseau. Les environnements VMware et OpenStack sont pris en charge.
Pour les installations opérateurs, VAS Experts utilise la plateforme de virtualisation vStack HCP, sur laquelle sont déployés DPI, CG-NAT, BNG, le module d’analyse QoE et les services de gestion. La plateforme permet d’exécuter les fonctions réseau dans un environnement virtualisé unique et simplifie la mise à l’échelle des services opérateur selon le modèle TelcoCloud.
Les serveurs ITPOD sont utilisés comme plateforme matérielle recommandée. Les solutions de l’entreprise sont conçues pour héberger des services réseau à forte charge et ont été testées pour leur compatibilité avec la plateforme de virtualisation vStack HCP.
Interface de supervision des performances
Dans une configuration à haute disponibilité, les composants NMS, DPI, CG-NAT, BNG et QoE sont répartis entre plusieurs nœuds de virtualisation. Si un hyperviseur devient indisponible, les autres composants continuent de fonctionner sur les nœuds voisins du cluster.
Dans les installations de grande envergure, les bases de données QoE et les services d’analyse sont déplacés vers des nœuds distincts — un point critique en cas de volumes importants de trafic utilisateur et de longues périodes de conservation des statistiques.
La sauvegarde couvre non seulement la couche système, mais aussi les données opérationnelles : configurations, bases de données QoE, licences, journaux d’événements et paramètres de service. Les sauvegardes peuvent être lancées manuellement via l’interface Web GUI ou la CLI, ou automatiquement selon une planification.
Les fichiers de sauvegarde peuvent être stockés localement ou exportés vers des systèmes de stockage externes via SFTP. Cela permet d’intégrer le NMS dans les processus existants de reprise après sinistre et de stockage des données.
Gestion des configurations
La gestion des paramètres de DPI, BNG, CG-NAT et des autres composants de la plateforme s’effectue de manière centralisée dans le NMS. Les configurations peuvent être modifiées via l’interface Web GUI, la CLI ou l’API.
Selon le type d’équipement, REST API, SNMP, SSH, HTTP(S) ou Netconf sont utilisés.
L’interface affiche la configuration actuelle du nœud, l’historique des modifications et l’auteur de chaque modification.
Section « Configuration » dans le module « Gestion DPI »
La comparaison entre deux versions quelconques de la configuration (diff) est disponible, avec mise en évidence des modifications.
Si la connexion avec un élément réseau est perdue, le NMS enregistre l’écart d’état et place l’objet en mode de désynchronisation. Une fois la connexion rétablie, le NMS synchronise automatiquement les configurations et ramène le nœud à son état actualisé.
Ce mécanisme est utile lors des mises à jour, des migrations et du basculement des services entre les sites.
La comparaison régulière des configurations permet de détecter les modifications manuelles effectuées en dehors du système de gestion. Une fois la connexion rétablie, le système peut automatiquement ramener la configuration du nœud à l’état de référence.
Supervision et métriques QoE
Le module QoE intégré à Stingray collecte des statistiques sur les connexions des utilisateurs et transmet les données au système d’analyse. Les données incluent les paramètres de trafic, la charge des interfaces et les indicateurs de qualité de service pour les abonnés.
Le NMS utilise ces données pour les tableaux de bord, les KPI et les rapports. L’interface permet de consulter :
- répartition du trafic par application ;
- RTT (Round-Trip Time) et le taux de retransmissions ;
- nombre de sessions utilisateur ;
- charge des services ;
- statistiques par segment de réseau.
Tableau de bord d’analyse QoE avec indicateurs de trafic, sessions et abonnés
Journalisation et audit des événements
Le système collecte de manière centralisée les événements provenant à la fois des composants du NMS et des éléments réseau gérés. Le journal comprend :
- actions des utilisateurs ;
- modifications de configuration ;
- événements système ;
- opérations sur les services ;
- événements de sécurité.
Les journaux sont centralisés au sein du NMS et peuvent être recherchés par date, type d’événement ou nœud spécifique. La période minimale de conservation des journaux est d’un mois, la durée réelle étant définie par la politique d’exploitation.
Syslog, SNMP traps et REST API sont pris en charge. Les alarmes et événements peuvent être traités aussi bien au sein du NMS que dans le périmètre existant de l’opérateur.
Journal des événements NAT dans l’analyse QoE
Rapports
Les rapports sont générés directement à partir de la base de données QoE. Il est possible de sélectionner la plage horaire, des nœuds spécifiques, des segments de réseau ou des applications individuelles.
La génération des rapports peut être lancée manuellement ou selon une planification. Les rapports terminés sont enregistrés dans l’espace personnel et peuvent être exportés vers des systèmes externes.
L’envoi par e-mail et l’exportation via l’interface Web sont pris en charge. Cela permet d’intégrer les rapports dans les processus d’exploitation existants sans génération manuelle de données.
Sécurité et exploitation
Pour l’accès au système, des protocoles sécurisés HTTPS, SSH et SFTP sont utilisés.
Le NMS prend en charge un modèle d’accès basé sur les rôles (RBAC). Les autorisations sont réparties entre le NOC, l’équipe d’exploitation, le service de sécurité de l’information et les prestataires externes. Par exemple, un groupe d’utilisateurs n’a accès qu’à la supervision et aux alarmes, tandis qu’un autre peut modifier les configurations DPI et BNG.
Configuration des rôles et des droits d’accès dans la section « Administrateur »
L’authentification s’effectue via LDAP, Active Directory, RADIUS ou SSO. Le système limite les connexions simultanées sous un même utilisateur. Toutes les actions des utilisateurs sont enregistrées dans le journal d’audit.
Il enregistre :
- modifications de configuration ;
- lancement de diagnostics ;
- opérations sur les services ;
- tentatives de connexion ;
- utilisation de l’API.
Journal des actions des utilisateurs
Conclusion
À mesure que l’infrastructure de l’opérateur se développe, la gestion des services réseau cesse d’être une tâche relevant d’équipes et d’interfaces isolées.
DPI, CG-NAT, BNG, QoE, les passerelles mobiles et d’autres fonctions réseau forment une plateforme de services unique, où les modifications apportées à un composant peuvent affecter le fonctionnement des services associés.
Stingray NMS regroupe ces composants au sein d’un circuit de gestion commun. Le système centralise les configurations, les alarmes, les statistiques, le QoE, l’audit et les intégrations avec les plateformes OSS/BSS externes. Grâce à cela, l’exploitation du réseau devient plus prévisible : moins d’opérations manuelles lors des changements, localisation plus rapide des incidents et audit plus transparent des actions du personnel.
