Traitement des données massives dans le cadre du programme QoE Stor

Le big data peut être utilisé par l’opérateur dans les scénarios suivants :

1. Comprendre la structure du trafic par protocoles et applications et sa dynamique pour élaborer des plans tarifaires attrayants, identifier les points de peering et optimiser les itinéraires.
2. Surveiller la qualité des liens applicatifs pour des applications spécifiques et réagir rapidement aux problèmes de trafic du réseau WAN.
3. Identifier les abonnés problématiques en fonction de la latence et des re-demandes de paquets afin de résoudre les problèmes et d’améliorer la fidélité des abonnés.
4. Surveiller de manière proactive les cybermenaces en fonction des statistiques d’appels des abonnés à l’aide de la base de données Kaspersky feed afin de réduire le nombre de BotNet sur le réseau.
5. Surveillez les attaques DDoS et réagissez à temps aux pics de trafic.

3 minutes pour construire un rapport sur 1 pétaoctet de données

Prenons l’exemple d’un opérateur avec 1 million d’abonnés. D’après notre expérience, on suppose qu’un opérateur de cette taille a environ 2 Tbps de trafic de pointe.

Pour travailler avec des cas d’affaires typiques, les opérateurs :

• Stocker les statistiques IPFIX « brutes » pendant 24 heures, ce qui représente environ 45 TB.
• Puis, à l’aide des algorithmes de qualité de l’expérience de Stor, les données sont agrégées pour le stockage et réduites d’un facteur 5. Les données agrégées sont généralement stockées pendant 3 mois, ce qui représente environ 900 TB .

Combiné à d’autres types de données (par exemple, le journal NAT ou le journal GTP), notre opérateur de référence s’élève à environ 1 pétaoctet .

Cependant, il n’est pas seulement important d’obtenir les données, mais aussi de s’assurer qu’elles sont disponibles et traitées rapidement. Les ingénieurs et les spécialistes du marketing de l’opérateur travaillent avec ces données tous les jours : ils élaborent des rapports sur différents champs et des filtres pour toute la profondeur du stockage des données. Pour le confort des utilisateurs, le temps de construction des rapports par filtres ne doit pas dépasser 3 minutes .

Les données de la base sont également utilisées régulièrement pour envoyer des rapports périodiques aux services de l’opérateur par e-mail/télégramme et pour élaborer des tableaux de bord.

Vous pouvez calculer le volume des statistiques de votre opérateur en utilisant la calculatrice.

Composants de la solution

L’acquisition des données se fait en plusieurs étapes :

1. Passage du trafic à travers SSG afin de l’analyser par signature (protocoles et applications).
2. Envoi de statistiques depuis le SSG via le protocole IPFIX (NetFlow v10), qui s’effectue via l’équilibreur ipfixcol2 afin de répartir uniformément les statistiques entre les nœuds et d’assurer une tolérance aux pannes en cas de défaillance d’un nœud.
3. Réception de statistiques sur le QoE Stor à l’aide de ipfixreceiver2.

Si le volume de trafic est supérieur à ce qu’un seul SSG peut gérer, un cluster DPI est utilisé. Le trafic est extrait de la partie centrale du réseau et envoyé à l’équilibreur de charge du SSG, qui répartit la charge de manière égale entre plusieurs serveurs SSG. L’équilibreur de charge est capable de gérer jusqu’à 800 Gbps de trafic en miroir.

Des informations plus détaillées sur le fonctionnement de l’équilibreur de charge sont disponibles dans notre base de connaissances.

Cluster QoE

QoE Stor utilise essentiellement une base de données ClickHouse avec la possibilité de créer un cluster de plusieurs nœuds :

• Un nœud maître est affecté au cluster, qui reçoit une demande de l’interface graphique et envoie des demandes au nœud esclave.
• Chaque nœud esclave crée un rapport basé sur ses propres données et l’envoie au nœud maître.
• Le nœud maître agrège les réponses reçues du nœud esclave et crée la représentation résultante pour la visualisation dans l’interface graphique.

Cette hiérarchie permet de réaliser une mise à l’échelle linéaire de la grappe lorsque de nouveaux nœuds sont ajoutés sans avoir à augmenter les performances du nœud maître. L’interface graphique fonctionne avec le cluster dans un mode spécial (activé par une option séparée dans les paramètres), modifiant les requêtes SQL de sorte que les nœuds construisent des rapports prêts à être collés. Sans ce mode, le cluster n’est qu’un stockage distribué, et les performances ne sont limitées que par les performances du nœud maître et la bande passante du réseau entre les nœuds de qualité de l’environnement.

Le QoE Stor traite les données en plusieurs étapes :

1. ipfixreceiver2 reçoit et écrit les données brutes dans un fichier texte à une fréquence spécifiée (10 sec.-10 min.) sur le default-disk.
2. Le post-processus effectue l’agrégation des données brutes afin de réduire l’espace de stockage et de remplir les tableaux pour l’élaboration des rapports. L’étape d’agrégation dure de 1 minute à 1 heure.

Plusieurs types de disques sont utilisés pour optimiser le coût du stockage :

• default – disques rapides pour recevoir les données et effectuer le processus d’agrégation, les SSD NVMe sont recommandés.
• chaud – disques pour le stockage pendant la période où il y aura une forte probabilité de demander des rapports sur ces données, généralement jusqu’à 3 mois.
• froid – disques lents de grand volume pour le stockage à long terme, il est recommandé d’utiliser des disques durs.

La période de stockage à chaque niveau est définie dans la configuration via l’interface graphique. Le déplacement des données entre les disques et le nettoyage des données s’effectuent automatiquement en fonction des paramètres. Il existe également un mécanisme de contrôle des débordements pour protéger la base de données.

Pour plus d’informations sur les avantages de Stingray Service Gateway et du module d’analyse QoE, veuillez contacter VAS Experts. Laissez une demande de test pour évaluer objectivement les capacités et les fonctionnalités du logiciel.