Visibilité des flux et cloud

Visibilité des flux et cloud

Apporter de la visibilité dans les environnements hyper-convergés et SD-WAN (1ère partie)

 

Un peu d’histoire

Il fut une époque où toutes les ressources de l’entreprise étaient à portée de main et où chaque site hébergeait ses propres ressources. Les réseaux WAN étaient encore trop onéreux et les débits pas assez élevés. L’administration du site s’effectuait en local, la réactivité était optimale, les temps de réponse étaient au rendez-vous et l’utilisateur satisfait.

tenedis_24967011

Puis, arriva l’ère de la centralisation, un temps où chacun a considéré que tout héberger sur un même site (avec reprise ou non) faciliterait la gestion des ressources et favoriserait la diminution du nombre des interlocuteurs. Les latences impliquées et les problématiques de disponibilité des accès entraina, au final, un besoin à la fois de contrôle et de visibilité sur les flux.

A cet instant, tout problème de performance entraina le constat très souvent erroné : « le réseau est en cause ». Et chacun oubliait que bien des applications développées et dimensionnées au départ pour des infrastructures à faible latence étaient elles-mêmes impactées par les points de blocage de la centralisation.

Ensuite, vint le temps de la rationalisation et de la virtualisation « tout de go ». Les entreprises imaginèrent que la virtualisation deviendrait l’élément clef de la performance mais elles oublièrent que la visibilité s’en trouverait compromise. Elles durent redoubler d’ingéniosité pour accéder à l’analyse de leurs trafics virtualisés.

Et suivit le temps de l’économie forte basée sur la sous-traitance de l’hébergement d’un service ou d’une infrastructure et permettant, certes, de réduire les coûts humains et d’équipements mais requérant encore et toujours plus de maitrise et de contrôle du trafic. A cette étape, apparurent les réseaux virtuels. Leur contrôle et le besoin de visibilité sur les architectures complexes ont obligé les acteurs de la métrologie à proposer des solutions de collecte plus denses et plus intelligentes. Une nouvelle vague de rationalisation via l’hyper-convergence débuta avec la fourniture de « boites noires » offrant :

  • Centralisation
  • Virtualisation des services applicatifs, réseaux et stockage
  • Intégrité des données
  • Haute-disponibilité

Certes, l’hyper-convergence permet, aujourd’hui, de simplifier les infrastructures physiques mais elle oblige aussi à repenser les méthodes de métrologie. Et l’arrivée du SD-WAN signe une nouvelle étape dans la longue histoire de l’évolution des infrastructures.

 

Le principe

Une « boite noire » regroupe les fonctionnalités de routage, firewalling, QoS, optimisation, load balancing et autres intelligences à venir.

Ainsi, la maitrise du routage et de ses mécanismes n’est plus obligatoirement du ressort des opérateurs. L’hybridation des réseaux (WAN/Internet) devient un automatisme et le choix d’une route au profit d’une autre pour des raisons de performance s’effectue naturellement sans action humaine. Pour les opérateurs, le SD-WAN est l’opportunité d’étendre leurs catalogues de service à moindre coût.

Mais quid de la visibilité et de l’assurance que le meilleur chemin est emprunté pour les flux sensibles ? Quelles garanties peuvent être offertes ? Et comment pouvez-vous, dans une problématique de performance, vous assurer du service délivré à vos utilisateurs ?

Quels sont les enjeux ?

Nous sommes tous d’accord. L’hyper-convergence est une avancée dans la simplification des moyens de délivrance des services. Il reste néanmoins nécessaire de garantir la performance du réseau et des applications de bout en bout, d’accéder à la visibilité des flux et des points de transit et de s’assurer que le choix du chemin emprunté est toujours le meilleur.
De plus, être capable de réactivité et d’identification de l’élément à problème dans la chaine de transmission (le Mean Time To Know) et être en mesure de réagir rapidement pour rétablir le service (le MTTR) font également parti des enjeux de la virtualisation globale.

tenedis-schema_24967740 (1)

Ainsi, il existe toujours une place forte pour la métrologie dans les environnements hyper-convergés. Identifier un problème de temps de réponse demandera toujours de déterminer qui, du client, du réseau, du serveur ou des tiers, est la cause de la dégradation d’un service. Bref, les enjeux restent inchangés mais les méthodes évoluent.

Nous aborderons dans un deuxième article les moyens à disposition pour analyser et identifier la cause de la dégradation d’un service.


Articles similaires

f300195583737e5330190a7f90d82c7b^^^^^^