Votre réseau est-il prêt pour la gestion du big data ?

Les entreprises sont assises sur des montagnes de données. Encore faut-il tester les capacités système avant d’envisager de les traiter.

La plupart des organisations sont assises sur des montagnes de données historiques dont elles ont notamment besoin pour des raisons comptables et fiduciaires ou pour des questions de compatibilité. Une chaine de grande distribution, par exemple, garde la trace de ses ventes : d’une part pour sa comptabilité et pour la gestion de ses stocks d’autre part.

De telles données, cependant, sont normalement transmises durant la nuit pour éviter de monopoliser la bande passante pendant la journée et cela est généralement acceptable dans ce qui représente pourtant un secteur extrêmement critique.

D’un autre côté, certains sont tentés de réduire l’utilisation du terme « big data » à des systèmes utilisant un stockage à circuits intégrés à haute capacité, pour un accès aux données le plus rapide possible et avec le moins de latence possible, et un traitement massivement parallèle (MPP) pour pouvoir fournir des données en temps réel ou presque. Le traitement des données à une telle vitesse peut être tout à fait être approprié pour certaines applications comme les transactions financières ou les décisions militaires, mais tous les services ne sont pas si sensibles à l’urgence.

Si les données de l’organisation sont conservées sur des disques mobiles répartis à travers tout un réseau de stockage SAN, cela engendre des latences qui peuvent paraitre insignifiantes sur une transaction unique, mais peuvent vite devenir importantes au fur et à mesure que le nombre de demandes d’accès augmente durant une analyse plus poussée des données. Si vous recueillez des données en temps réel sur un réseau WAN, cela dictera la vitesse d’accessibilité des données. Et si le traitement des données est lui-même distribué entre plusieurs centres de données, cela peut avoir un réel impact sur le temps d’analyse réel.

Un  prérequis indispensable à toute exploitation planifiée du big data est de tester le système pour voir s’il sera capable de fournir les données de manière suffisamment rapide et fiable sous toute une gamme de conditions d’exploitation les plus réalistes possibles. A moins que l’exploitation du big data soit séparée du reste du réseau, il sera également vital de tester pour voir l’impact qu’elle aura : d’autres processus en court vont-ils « planter » ou le réseau sera-t-il seulement ralenti au détriment d’autres utilisateurs ?

Il y a inévitablement beaucoup d’inconnues lorsque l’on se lance dans une nouvelle aventure comme celle-ci. De nombreux tests seront nécessaires, de même qu’une grande flexibilité permettant d’ajuster tous les paramètres d’exploitation et, dans le cas d’un test défaillant, de réinitialiser le système et de tout recommencer. Cela requiert des méthodologies de tests à la fois sophistiquées et automatisées qui permettent de couvrir la totalité des nombreuses variables possibles.

Heureusement, la meilleure technologie de test réseau actuelle est capable de fournir tout cela via une interface utilisateur graphique très simple qui permet à des tests sophistiqués d’être à la fois mis en place rapidement (sans avoir besoin des compétences de spécialistes du chiffrage), gardés en mémoire et lancés automatiquement pour une mise à l’épreuve cohérente du réseau à travers toute une série de tests.

Modéliser des types de trafics vraiment réalistes requiert plus qu’une simple injection de données aléatoires : les meilleurs outils de tests vont en effet recréer l’état du niveau applicatif réel, la modélisation des cookies, les sessions d’identification, les traductions NAT d’adresses IP, les modifications engendrées par l’ALG, les défis d’authentification, les lenteurs et les checksums.

Et, lorsque les réseaux testés sont encombrés dans le cadre d’une exploitation normale, des algorithmes spécifiques vont simuler le flux TCP et le contrôle des congestions, changeant ainsi à la fois le comportement de l’outil de test et de la cible. Les meilleurs outils de tests sont en effet conçus pour se comporter exactement de la même manière qu’un client réel le ferait dans les mêmes circonstances.

Opérer une transition d’une très grande base de données vers des ressources big data, c’est un peu comme demander à un employé de bureau sédentaire de se lever et de prendre part à un marathon : ce n’est pas une chose impossible, mais cela dépend de la manière dont on va tester l’état physique de l’employé et planifier avec discernement un entrainement adapté pour qu’il puisse remplir son nouveau rôle avec succès.

Sans l’utilisation des meilleures solutions et méthodes de tests, la migration vers le  big data serait un peu comme se risquer à sauter dans le vide sans savoir où et comment l’on va atterrir.

Crédit photos : Google.