Résolution des problèmes de performances réseau

Vue d’ensemble

Azure met à votre disposition un moyen stable et rapide de vous connecter à Azure à partir de votre réseau local. Les méthodes telles que le VPN de site à site et ExpressRoute sont couramment utilisées par les clients de grande et petite tailles pour exécuter leurs activités dans Azure. Mais que se passe-t-il quand les performances ne sont pas à la hauteur de vos attentes ou expériences passées ? Cet article peut vous aider à standardiser la façon dont vous testez et planifiez votre environnement.

Vous apprendrez à tester la latence réseau et la bande passante entre deux hôtes de façon aisée et cohérente. Vous bénéficierez également de conseils pour examiner le réseau Azure afin d’isoler les points problématiques. Le script PowerShell et les outils présentés nécessitent deux hôtes sur le réseau (à chaque extrémité de la liaison testée). L’un des hôtes doit être doté de Windows Server ou Windows Desktop, l’autre peut être doté de Windows ou de Linux.

Composants réseau

Avant de nous plonger dans la résolution des problèmes, examinons certains composants et termes courants. Par le biais de cette discussion, nous nous penchons sur chaque composant de la chaîne de bout en bout qui assure la connectivité dans Azure.

Sur le plan général, il y a trois domaines de routage réseau principaux :

• Réseau Azure (cloud bleu)
• Internet ou WAN (cloud vert)
• Réseau d’entreprise (cloud orange)

Observons brièvement chaque composant du diagramme, de droite à gauche :

• Machine virtuelle : le serveur peut comporter plusieurs cartes réseau. Vérifiez que les itinéraires statiques, les itinéraires par défaut et les paramètres du système d'exploitation envoient et reçoivent le trafic comme prévu. En outre, chaque référence de machine virtuelle a une restriction de bande passante. Si vous utilisez une référence de machine virtuelle plus petite, le trafic est limité par la bande passante disponible pour la carte réseau. Nous vous recommandons d’utiliser un DS5v2 pour le test afin de garantir une bande passante adéquate sur la machine virtuelle.

• Carte réseau : vérifiez que vous connaissez l’adresse IP privée qui est assignée à la carte réseau en question.

• Groupe de sécurité réseau (NSG) de la carte réseau : plusieurs NSG spécifiques peuvent être appliqués au niveau de la carte réseau. Vérifiez que l’ensemble de règles NSG est approprié pour le trafic à faire passer. Par exemple, assurez-vous que les ports 5201 pour iPerf, 3389 pour RDP ou 22 pour SSH sont ouverts afin de permettre le passage du trafic test.

• Sous-réseau de réseau virtuel : la carte réseau est assignée à un sous-réseau spécifique ; vérifiez que vous le connaissez, ainsi que les règles qui lui sont associées.

• Groupe de sécurité réseau de sous-réseau : tout comme la carte réseau, des groupes de sécurité réseau peuvent être appliqués à ce sous-réseau. Assurez-vous que l’ensemble de règles NSG est approprié pour le trafic à faire passer. Pour le trafic entrant sur la carte réseau, le groupe de sécurité réseau du sous-réseau s'applique en premier, suivi de celui de la carte réseau. Pour le trafic sortant de la machine virtuelle, le groupe de sécurité réseau s'applique en premier, suivi de celui du sous-réseau.

• UDR de sous-réseau : les itinéraires définis par l'utilisateur (UDR) peuvent diriger le trafic vers un tronçon intermédiaire (comme un pare-feu ou un équilibreur de charge). Déterminez si un UDR est en place pour votre trafic. Si tel est le cas, renseignez-vous sur sa direction et sur le rôle que jouera le tronçon suivant sur votre trafic. Par exemple, un pare-feu pourrait laisser passer une partie du trafic et en refuser une autre entre les mêmes hôtes.

• Sous-réseau de passerelle / groupe de sécurité réseau / UDR : tout comme le sous-réseau de la machine virtuelle, le sous-réseau de passerelle peut avoir des groupes de sécurité réseau et des UDR. Vérifiez leur présence éventuelle et leur impact sur le trafic.

• Passerelle de réseau virtuel (ExpressRoute) : une fois le peering (ExpressRoute) ou le VPN activé, peu de paramètres peuvent affecter le routage du trafic ou l’existence de ce routage. Si vous disposez d’une passerelle de réseau virtuel connectée à plusieurs circuits ExpressRoute ou tunnels VPN, vous devez connaître les paramètres de pondération de la connexion. La pondération de la connexion affecte les préférences de connexion et détermine le chemin emprunté par votre trafic.

• Filtre d'itinéraire (non affiché) : un filtre d'itinéraire est nécessaire lors de l'utilisation du Peering Microsoft via ExpressRoute. Si vous ne recevez aucun itinéraire, vérifiez que le filtre d'itinéraire est correctement configuré et appliqué au circuit.

À ce stade, vous êtes sur la partie WAN de la liaison. Ce domaine de routage peut être votre fournisseur de services, votre réseau étendu d’entreprise ou Internet. De nombreux tronçons, appareils et entreprises sont concernés par ces liaisons, ce qui peut compliquer la résolution des problèmes. Vous devez d'abord écarter Azure et vos réseaux d'entreprise avant de pouvoir examiner les tronçons situés entre les deux.

Dans le diagramme précédent, à l’extrême gauche se trouve votre réseau d’entreprise. Selon la taille de votre entreprise, ce domaine de routage peut regrouper quelques périphériques réseau entre vous et le réseau étendu ou plusieurs couches de périphériques sur un réseau de campus ou d’entreprise.

Compte tenu de la complexité de ces trois environnements réseau de haut niveau, il est souvent préférable de commencer par les bords, et d'essayer d'indiquer où les performances sont satisfaisantes et où elles sont dégradées. Cette approche peut permettre d'identifier le domaine de routage problématique des trois. Vous pouvez ensuite concentrer votre résolution sur cet environnement spécifique.

Outils

La plupart des problèmes réseau peuvent être analysés et isolés à l’aide d’outils de base tels que ping et traceroute. Il est rare qu'il soit nécessaire d'effectuer une analyse de paquets à l'aide d'outils tels que Wireshark.

Pour vous aider à résoudre les problèmes, la boîte à outils de connectivité Azure (AzureCT) a été développée pour placer une partie de ces outils dans un package simple. Pour les tests de performances, des outils comme iPerf et PSPing peuvent vous fournir des informations sur votre réseau. Relativement facile à utiliser, iPerf est un outil couramment utilisé pour les tests de performances de base. PSPing est un outil de test Ping développé par SysInternals. PSPing permet d'effectuer des tests ping ICMP et TCP pour atteindre un hôte distant. Ces deux outils sont légers et vous pouvez les « installer » simplement en copiant les fichiers dans un répertoire sur l’hôte.

Ces outils et méthodes sont disponibles dans un module PowerShell (AzureCT) que vous pouvez installer et utiliser.

AzureCT : la boîte à outils de connectivité Azure

Le module PowerShell AzureCT comporte deux composants : test de la disponibilité et test de performance. Ce document ne concernant que le test de performance, concentrons-nous sur les deux commandes de test de la performance de la liaison incluses dans ce module PowerShell.

L’utilisation de cette boîte à outils pour tester les performances comprend trois étapes de base.

1. Installer le module PowerShell.

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   
   

   Cette commande télécharge le module PowerShell et l’installe localement.

2. Installer les applications de prise en charge.

   Install-LinkPerformance
   

   Cette commande AzureCT installe iPerf et PSPing dans un nouveau répertoire C:\ACTTools et ouvre également les ports du Pare-feu Windows pour autoriser le trafic ICMP et via le port 5201 (iPerf).

3. Exécuter le test de performance.

   Sur l’hôte distant, vous devez d’abord installer et exécuter iPerf en mode serveur. Vérifiez également que l’hôte distant est à l’écoute sur le port 3389 (RDP pour Windows) ou 22 (SSH pour Linux), et qu’il autorise le trafic sur le port 5201 pour iPerf. Si l'hôte distant est Windows, installez AzureCT et exécutez la commande Install-LinkPerformance. La commande configure alors iPerf et les règles de pare-feu nécessaires pour démarrer iPerf en mode serveur.

   Une fois que l’ordinateur distant est prêt, ouvrez PowerShell sur l’ordinateur local et démarrez le test :

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Cette commande exécute une série de tests de charge et de latence simultanés pour aider à estimer la latence et la capacité de la bande passante de votre liaison réseau.

4. Examiner la sortie des tests.

   Le format de sortie PowerShell est similaire à ceci :

   

   Les résultats détaillés de tous les tests PSPing et iPerf se trouvent dans des fichiers texte individuels dans le répertoire des outils AzureCT à l’emplacement « C:\ACTTools ».

Dépannage

Si le test de performances ne fournit pas les résultats escomptés, une approche progressive, étape par étape, peut s'avérer pertinente. Compte tenu du nombre de composants en jeu, une approche systématique permet d’obtenir une résolution plus rapidement. Une résolution systématique vous évitera d'avoir à effectuer plusieurs fois des tests inutiles.

Notes

Dans notre scénario, nous devons résoudre un problème de performance, pas un problème de connectivité. Pour isoler le problème de connectivité au réseau Azure, suivez l’article Vérification de la connectivité ExpressRoute.

Tout d’abord, reconsidérez vos hypothèses. Vos attentes sont-elles raisonnables ? Par exemple, si vous avez un circuit ExpressRoute de 1 Gbit/s et une latence de 100 ms, vous ne pouvez pas vous attendre à bénéficier de 1 Gbits/s sur la totalité du trafic compte tenu des caractéristiques de performances de TCP sur les liaisons à latence élevée. Consultez la section Références pour plus d’informations sur les hypothèses de performance.

Nous vous recommandons ensuite de commencer à la périphérie des domaines de routage et d'essayer d'isoler le problème sur un seul domaine de routage principal. Vous pouvez commencer par le réseau d'entreprise, le WAN ou le réseau Azure. Les gens accusent souvent la « boîte noire » qui se trouve sur leur chemin. Bien que cette accusation soit un peu facile, la boîte noire peut néanmoins retarder considérablement la résolution, en particulier si le problème se trouve dans une zone où vous pouvez apporter des modifications pour résoudre le problème. Veillez à procéder aux vérifications nécessaires avant de contacter votre fournisseur de services ou fournisseur de services Internet.

Une fois que vous avez identifié le domaine de routage principal qui semble contenir le problème, vous devez créer un diagramme de la zone en question. Lorsque vous dessinez un diagramme, vous pouvez traiter et isoler méthodiquement le problème. Vous pouvez planifier des points de tests et mettre à jour le plan à mesure que vous écartez des zones ou approfondir des analyses à mesure que le test progresse.

Une fois votre diagramme prêt, commencez par diviser le réseau en segments afin de cerner le problème petit à petit. Déterminez où il fonctionne et où il ne fonctionne pas. Continuez à déplacer vos points de tests pour isoler le composant responsable.

En outre, n’oubliez pas d’examiner d’autres couches du modèle OSI. Il est facile de se concentrer sur le réseau et les couches 1 à 3 (couches Physique, Liaison de données et Réseau), mais les problèmes peuvent également se situer au niveau de la couche 7 (Application). Conservez une certaine ouverture d’esprit et vérifiez les hypothèses.

Résolution avancée des problèmes quand ExpressRoute est utilisé

Si vous ignorez le périmètre réel du cloud, l’isolation des composants Azure peut être difficile. Quand ExpressRoute est utilisé, le périmètre est un composant réseau appelé MSEE (Microsoft Enterprise Edge). Lorsque vous utilisez ExpressRoute, MSEE est le premier point de contact au sein du réseau de Microsoft, et le dernier tronçon à la sortie de ce dernier. Quand vous créez un objet de connexion entre votre passerelle de réseau virtuel et le circuit ExpressRoute, vous établissez en fait une connexion à MSEE. Identifier MSEE comme le premier ou le dernier tronçon en fonction de la direction du trafic est essentiel pour isoler un problème de réseau Azure. Le fait de connaître la direction permet de déterminer si le problème se situe dans Azure, ou plus en aval au niveau du WAN ou du réseau d’entreprise.

Notes

Notez que MSEE ne se trouve pas dans le cloud Azure. ExpressRoute est en fait à la périphérie du réseau Microsoft, pas véritablement dans Azure. Une fois que vous êtes connecté avec ExpressRoute à MSEE, vous êtes connecté au réseau de Microsoft, à partir duquel vous pouvez accéder à n’importe quel service cloud, tel que Microsoft 365 (avec le Peering Microsoft) ou Azure (avec le Peering privé et/ou Microsoft).

Si deux réseaux virtuels sont connectés au même circuit ExpressRoute, vous pouvez procéder à une série de tests pour isoler le problème dans Azure.

Plan de test

1. Exécutez le test Get-LinkPerformance entre VM1 et VM2. Ce test indique si le problème est local ou non. Si ce test génère des résultats acceptables concernant la latence et la bande passante, vous pouvez marquer le réseau virtuel local comme étant correct.

2. En supposant que le trafic du réseau virtuel local est correct, exécutez le test Get-LinkPerformance entre VM1 et VM3. Ce test teste la connexion via le réseau Microsoft jusqu’au MSEE, puis jusqu’à Azure. Si ce test génère des résultats acceptables concernant la latence et la bande passante, vous pouvez marquer le réseau Azure comme étant correct.

3. Si Azure est écarté, vous pouvez procéder à une série de tests similaire sur votre réseau d'entreprise. Si ces tests sont également concluants, il est temps de collaborer avec votre fournisseur de services ou fournisseur de services Internet pour diagnostiquer votre connexion WAN. Exemple : Exécuter ce test entre deux succursales, ou entre votre bureau et un serveur de centre de données. En fonction de ce que vous testez, recherchez les points de terminaison tels que les serveurs et les PC clients qui peuvent utiliser ce chemin.

Important

Il est essentiel que pour chaque test vous notiez l’heure du jour à laquelle vous l’exécutez et que vous centralisiez l’enregistrement des résultats. Chaque série de tests doit avoir une sortie identique afin que vous puissiez comparer les données résultantes entre les séries de tests et que vous n’ayez pas de « trous » dans les données. L’importance de la cohérence entre les différents tests est la raison principale qui nous amène à utiliser la boîte à outils AzureCT pour la résolution des problèmes. Ce ne sont pas les scénarios de charge exacts que nous exécutons qui importent, mais le fait que nous obtenons une sortie de données et de test cohérente à l’issue de chaque test. Le fait d’enregistrer l’heure et d’avoir systématiquement des données cohérentes s’avère particulièrement utile si vous êtes amené à constater que le problème est sporadique. Faites preuve de diligence avec la collecte de données en amont ; vous devriez ainsi éviter de passer des heures à tester les mêmes scénarios plusieurs fois.

Le problème étant isolé, que devons-nous faire ?

Plus vous isolez le problème, plus la solution est rapide. Parfois, vous atteignez une limite dans votre processus de résolution. Par exemple, vous constatez que la liaison via votre fournisseur de services emprunte des tronçons en Europe, alors que la totalité du chemin est censée se trouver en Asie. À ce stade, vous devez vous faire aider. La personne à qui vous vous adressez dépend du domaine de routage sur lequel vous isolez le problème. Si vous pouvez le réduire à un composant spécifique, c'est encore mieux.

Pour les problèmes de réseau d'entreprise, votre service informatique interne ou votre fournisseur de services peut vous aider à configurer l'appareil ou à réparer le matériel.

Dans le cadre de la résolution des problèmes liés au WAN, une bonne pratique consiste à partager vos résultats de test avec votre fournisseur de services ou d’accès à Internet pour possiblement faciliter son travail. En prenant connaissance de vos résultats de test, il peut décider de ne pas refaire les tâches que vous avez déjà effectuées. Cependant, il souhaitera peut-être vérifier lui-même vos résultats. Il s’agit du principe « faire confiance, mais vérifier ».

Avec Azure, une fois que vous avez isolé le problème aussi précisément que possible, vous pouvez examiner la documentation sur le réseau Azure et, si nécessaire, ouvrir un ticket de support.

References

Attentes en termes de latence et de bande passante

Conseil

La latence géographique (miles ou kilomètres) entre les points de terminaison que vous testez est de loin le composant de la latence le plus important. Même s’il existe une latence liée aux équipements (composants physiques et virtuels, le nombre de tronçons, etc.), il s’avère que le critère géographique est le composant le plus important de la latence globale concernant les connexions WAN. Il est également important de noter que la distance est la distance en fibre optique, pas la distance à vol d’oiseau ou routière. Cette distance est extrêmement difficile à obtenir avec précision. Ainsi, nous utilisons généralement un outil de calcul de distance entre villes sur Internet. Cette méthode est certes approximative, mais elle suffit pour définir une attente générale.

Par exemple, nous avons une installation ExpressRoute à Seattle, Washington aux États-Unis. Le tableau suivant présente la latence et la bande passante que nous avons constatées en effectuant des tests à différents emplacements Azure. Nous avons estimé la distance géographique entre chaque fin du test.

Configuration des tests :

• Un serveur physique exécutant Windows Server 2016 doté d’une carte réseau 10 Gbits/s, connecté à un circuit ExpressRoute.

• Un circuit ExpressRoute Premium 10 Gbits/s à l’emplacement identifié avec le peering privé activé.

• Un réseau virtuel Azure doté d’une passerelle UltraPerformance dans la région spécifiée.

• Une machine virtuelle DS5v2 exécutant Windows Server 2016 sur le réseau virtuel. La machine virtuelle n’a pas été jointe à un domaine et a été générée à partir de l’image Azure par défaut (sans optimisation ou personnalisation) à l’aide de la boîte à outils AzureCT installée.

• Tous les tests utilisent la commande Get-LinkPerformance de la boîte à outils AzureCT, à raison d'un test de charge de 5 minutes pour chacune des six séries de tests. Par exemple :

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Pour chaque test, la charge du flux de données allait du serveur physique local (client iPerf à Seattle) à la machine virtuelle Azure (serveur iPerf dans la région Azure répertoriée).

• Les données de la colonne « Latence » sont issues du test avec absence de charge (test de latence TCP sans exécution d’iPerf).

• Les données de la colonne « Bande passante maximale » sont issues du test de charge de 16 flux TCP avec une taille de fenêtre de 1 Mo.

Résultats de latence et de bande passante

Important

Les données numériques ci-dessous ne sont indiquées qu’à titre de référence générale. De nombreux facteurs affectent la latence et, bien que ces valeurs soient cohérentes sur la durée, les conditions dans Azure ou les réseaux des fournisseurs de services peuvent envoyer du trafic via différents chemins à tout moment, ce qui peut impacter la latence et la bande passante. En règle générale, ces modifications n’entraînent pas de différences significatives.

ExpressRoute Emplacement	Azure Région	Distance estimée (km)	Latence	1 Session Bande passante	Maximale Bande passante
Seattle	USA Ouest 2	191 km	5 ms	262,0 Mbits/s	3,74 Gbits/s
Seattle	USA Ouest	1\.094 km	18 ms	82,3 Mbits/s	3,70 Gbits/s
Seattle	USA Centre	2\.357 km	40 ms	38,8 Mbits/s	2,55 Gbits/s
Seattle	États-Unis - partie centrale méridionale	2\.877 km	51 ms	30,6 Mbits/s	2,49 Gbits/s
Seattle	Centre-Nord des États-Unis	2\.792 km	55 ms	27,7 Mbits/s	2,19 Gbits/s
Seattle	USA Est 2	3\.769 km	73 ms	21,3 Mbits/s	1,79 Gbit/s
Seattle	USA Est	3\.699 km	74 ms	21,1 Mbits/s	1,78 Gbit/s
Seattle	Japon Est	7\.705 km	106 ms	14,6 Mbits/s	1,22 Gbit/s
Seattle	Sud du Royaume-Uni	7\.708 km	146 ms	10,6 Mbits/s	896 Mbits/s
Seattle	Europe Ouest	7\.834 km	153 ms	10,2 Mbits/s	761 Mbits/s
Seattle	Australie Est	12.484 km	165 ms	9,4 Mbits/s	794 Mbits/s
Seattle	Asie Sud-Est	12.989 km	170 ms	9,2 Mbits/s	756 Mbits/s
Seattle	Brésil Sud *	10.930 km	189 ms	8,2 Mbits/s	699 Mbits/s
Seattle	Inde Sud	12.918 km	202 ms	7,7 Mbits/s	634 Mbits/s

* La latence au Brésil est un bon exemple où la distance à vol d’oiseau diffère considérablement de la distance en fibre optique. Alors que la latence devrait normalement se situer autour de 160 ms, elle s'élève à 189 ms. La différence de latence semble indiquer un problème réseau quelque part. Mais en réalité, la fibre optique ne rejoint pas le Brésil en ligne droite. Il faut donc s'attendre à environ 1 000 km de trajet en plus pour rejoindre le Brésil depuis Seattle.

Notes

Ces nombres doivent être pris en compte, mais ils ont été testés à l’aide d’AzureCT qui est basé dans IPERF dans Windows via PowerShell. Dans ce scénario, IPERF ne respecte pas les options TCP Windows par défaut du facteur de mise à l’échelle, mais utilise un nombre de décalages beaucoup plus faible pour obtenir la taille de la fenêtre TCP. Les nombres représentés ici ont été calculés à l’aide des valeurs IPERF par défaut et sont donnés à titre de référence générale uniquement. En paramétrant les commandes IPERF avec un commutateur -w et une grande taille de fenêtre TCP, un meilleur débit peut être obtenu sur de longues distances, présentant des chiffres de débit nettement meilleurs. En outre, pour s’assurer qu’un ExpressRoute utilise la bande passante complète, il est idéal d’exécuter l’IPERF dans l’option multithread à partir de plusieurs machines simultanément afin de s’assurer que la capacité de calcul est en mesure d’atteindre des performances de liaison maximales et n’est pas limitée par la capacité de traitement d’une seule machine virtuelle. Pour obtenir les meilleurs résultats Iperf sur Windows, utilisez « Set-NetTCPSetting -AutoTuningLevelLocal Experimental ». Vérifiez vos stratégies organisationnelles avant d’apporter des modifications.

Étapes suivantes

• Télécharger la boîte à outils de connectivité Azure
• Suivre les instructions pour tester le niveau de performance des liaisons