MtoM Mag - Le journal de l'MtoM.

« C’est la faute au réseau ! » : l’expression vous est sans doute familière, en particulier si vous faites partie d’une équipe d’exploitation réseau. Car en cas d’incident de performance sur vos applications, le réseau est souvent le premier à être montré du doigt, quand bien même la cause du dysfonctionnement n’a pas été clairement identifiée. L’intention n’est pas malveillante : accuser le réseau est une façon commune de verbaliser des frustrations face aux problèmes de performance et à la complexité d’en identifier les origines.

Pour ceux qui ont un peu d’expérience en matière de réseau, ce reproche systématique, dès qu’une application montre des faiblesses, peut s’avérer... agaçant. Mais restons objectif : après tout, c’est parfois vraiment de la faute du réseau !

Quand le réseau tombe, ou qu’il ne fonctionne pas comme il devrait, nous sommes tous d’accord pour dire qu’il doit être réparé ou optimisé. Mais il est beaucoup plus probable aujourd’hui que les plaintes émises par vos utilisateurs soient à mettre sur le compte d’interactions subtiles et inattendues entre l’application et le réseau, plutôt que sur des lenteurs de ce dernier. C’est d’autant plus vrai que les réseaux se sont modernisés pour prendre en charge les besoins exponentiels des applications. Des réseaux toujours plus rapides, grâce notamment à l’intégration de solutions d’optimisation et de qualité de service, afin de satisfaire la performance des échanges applicatifs (sans oublier les équipements de sécurité et leurs impacts).

Alors, si ce n’est pas la faute du réseau, ni de l’application, ces problèmes de performance applicative sont en réalité le résultat d’une mauvaise transportabilité de l’application sur le réseau. Pris indépendamment, les designs réseau et applicatifs ne sont jamais forcément mauvais : c’est lorsqu’ils fonctionnent ensemble qu’ils peuvent le devenir.

Optimiser le réseau, oui... mais comment ?

Pourquoi ne pas tout simplement construire un réseau optimum ? En résumé, une très grande bande-passante, et très peu de latence. Ou, si l’on pousse à l’extrême, une bande-passante illimitée et zéro latence.

Au-delà du fait qu’un réseau sans latence serait incapable d’atteindre des postes à distance, il faut aussi réaliser que même si elle est réputée peu coûteuse, la bande-passante n’en est pas pour autant gratuite, en particulier sur de longues distances ou à l’international.

Sans compter que chaque type d’application et ses protocoles (TelNet, ICA, PcoIP, VoIP, batch d’archivage, etc.) présente une sensibilité différente aux caractéristiques de base du réseau, comme la bande-passante, la latence et l’instabilité. Construire un réseau « optimum », c’est donc d’abord comprendre le type de trafic applicatif qu’il est supposé transporter.

Or, les réseaux ne sont pas destinés à un seul et unique usage, pas plus qu’ils ne se résument à de simples considérations de performance. En réalité, il faut traiter ces différentes sensibilités avec des fonctionnalités spécifiquement conçues pour améliorer la performance sur certains types d’application. Parmi ces fonctionnalités, citons par exemple la QoS, la mise en cache, les CDN, ou encore les techniques d’optimisation WAN qui permettent de réduire le volume de transferts de données et les coûts des mécanismes TCP, dont la mise en œuvre est quasiment incontournable pour garantir l’intégrité des données échangées.

Appliquées judicieusement, ces fonctionnalités améliorent la performance applicative et la qualité de service du réseau. Le mot clé ici est « judicieusement » : il n’est en effet pas rare de voir des modifications destinées à améliorer la performance générale conduire directement ou indirectement à des conséquences négatives, faute d’avoir été correctement évaluées ou déployées.

Les apparences sont parfois trompeuses : ne vous trompez pas de cible !

Prenons le cas d’une entreprise dont l’un des sites clients rencontrait un problème de performance. Il se trouve que le débit de serveur à serveur était bien plus faible que ce qu’il aurait dû être, ralentissant d’autant plus les données nécessaires au diagnostic pour d’autres applications. Tout le monde était persuadé que c’était « la faute au réseau ». En réalité, tout fonctionnait correctement jusqu’à ce que l’un des serveurs soit déplacé dans un autre datacenter disposant d’un accès WAN plus conséquent....

Une analyse approfondie du comportement de l’application et de TCP - dont on sait qu’il dégrade potentiellement les performances quand la latence du réseau est plus grande - ont permis de révéler une mauvaise configuration au niveau de la fenêtre de réception TCP du destinataire. Avec une bande-passante pourtant plus importante que nécessaire, cette fenêtre TCP ne s’adaptait pas pour profiter du meilleur débit disponible.

Les développeurs ont trouvé un début de réponse en identifiant le fait que l’application allouait un buffer de réception calibré pour des communications de serveur à serveur proches, ou lointains si le volume de fichiers à transférer n’est pas trop élevé. En revanche, malgré une large bande-passante, une latence à peine plus grande, mais un volume de trafic grossissant au fur à mesure de l’usage de l’application par les utilisateurs, le petit buffer alloué par l’application entraînait un contrôle de flux TCP suffisamment inefficace pour ralentir l’échange et créer un problème pour l’utilisateur final.

En résumé, c’est bien souvent la combinaison de plusieurs événements qui créent des contraintes de performance : d’origine physique (sur l’infrastructure), et d’origine logique (sur l’application et les protocoles utilisés). Dans l’exemple cité plus haut, la cause physique du problème est le volume de données en hausse à transmettre avec une latence supérieure, tandis que la cause logique est la taille limitée de la fenêtre TCP imposée par l’application.

L’amélioration des performances d’une application via le réseau doit donc passer par une compréhension de leurs interactions réciproques. Cette compréhension, permise avec des solutions d’APM nouvelle génération, aide par ailleurs à affiner les efforts de troubleshooting, en évitant de se perdre en conjectures quant à la responsabilité du réseau OU de l’application, en cas de problème de performance.

http://www.dynatrace.com