Partage via

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

  • Article

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 toutes les 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 recevrez é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, et 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.

Diagramme d’un domaine de routage réseau entre un site local vers Azure à l’aide d’ExpressRoute ou d’un VPN.

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 de carte réseau : il peut y avoir des groupes de sécurité réseau spécifiques appliqués au niveau de la carte réseau. Assurez-vous 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 affectée à un sous-réseau spécifique. Assurez-vous de connaître celui-ci et les règles associées à ce sous-réseau.

  • Groupe de sécurité réseau de sous-réseau : tout comme la carte réseau, des groupes de sécurité réseau peuvent également être appliqués au niveau du 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.

Étant donné la complexité de ces trois environnements réseau généraux différents, il est souvent optimal de démarrer à la périphérie et d’essayer de déterminer où les performances sont bonnes et où elles se dégradent. 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 performance 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 se concentre sur les tests de performance, en particulier les deux commandes de performances de liaison dans ce module PowerShell.

L’utilisation de cette boîte à outils pour les tests de performance comprend les trois étapes de base suivantes :

  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 les ports du Pare-feu Windows pour autoriser le trafic ICMP et celui du port 5201 (iPerf).

  3. Exécuter le test de performance

    Sur l’hôte distant, commencez par installer et exécuter iPerf en mode serveur. Vérifiez 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 pour configurer iPerf et les règles de pare-feu nécessaires.

    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 estimer la latence et la capacité de la bande passante de votre liaison réseau.

  4. Passer en revue la sortie du test

    Le format de sortie PowerShell est similaire à ceci :

    Capture d’écran de la sortie PowerShell du test de performances des liaisons.

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

Dépannage

Si les résultats des tests de performances ne sont pas ceux attendus, suivez une approche systématique pour identifier le problème. Compte tenu du nombre de composants dans le chemin, un processus pas à pas est plus efficace que les tests aléatoires.

Remarque

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

  1. Reconsidérer vos hypothèses

    Assurez-vous que vos attentes sont raisonnables. Par exemple, avec un circuit ExpressRoute de 1 Gbits/s et 100 ms de latence, l’attente de l’intégralité de 1 Gbit/s du trafic est irréaliste en raison des caractéristiques de performances du protocole TCP sur des liens à latence élevée. Consultez la section Références pour plus d’informations sur les hypothèses de performance.

  2. Démarrer à la périphérie du réseau

    Commencez à la périphérie des domaines de routage et essayez d’isoler le problème sur un seul domaine de routage principal. Évitez de blâmer la « boîte noire » dans le chemin sans examen approfondi, car cela peut retarder la résolution.

  3. Créer un diagramme

    Dessinez un diagramme de la zone en question pour travailler de façon méthodique et isoler le problème. Planifiez les points de test et mettez à jour la carte au fur et à mesure que vous effacez les zones ou les approfondissez.

  4. Diviser pour mieux régner

    Segmentez le réseau et réduisez le problème. Identifiez l’endroit où il fonctionne et où ce n’est pas le cas, et continuez à déplacer vos points de test pour isoler le composant incriminé.

  5. Prendre en considération toutes les couches OSI

    Bien qu’il soit courant de se concentrer sur le réseau et les couches 1 à 3 (couches physiques, données et réseau), n’oubliez pas que des problèmes peuvent également survenir au niveau de la couche 7 (couche Application). Conservez une certaine ouverture d’esprit et vérifiez toutes les hypothèses.

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

L’isolation des composants Azure peut être difficile si vous ne savez pas où se trouve la périphérie du cloud. Avec ExpressRoute, la périphérie est un composant réseau appelé MSEE (Microsoft Enterprise Edge). Le MSEE est le premier point de contact dans le réseau de Microsoft et le dernier tronçon lors de son départ. Quand vous créez une connexion entre votre passerelle de réseau virtuel et le circuit ExpressRoute, vous établissez une connexion à MSEE. La reconnaissance du MSEE comme premier ou dernier tronçon est essentielle pour isoler un problème de mise en réseau Azure. Connaître la direction du trafic permet de déterminer si le problème se trouve dans Azure ou en aval dans le réseau d’entreprise ou le réseau étendu.

Diagramme de plusieurs réseaux virtuels connectés à un circuit ExpressRoute.

Remarque

Le MSEE ne se trouve pas dans le cloud Azure. ExpressRoute est à la périphérie du réseau Microsoft, pas véritablement dans Azure. Une fois connecté avec ExpressRoute à MSEE, vous êtes connecté au réseau de Microsoft, ce qui vous permet d’accéder à des services cloud, comme 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 effectuer des tests pour isoler le problème dans Azure.

Plan de test

  1. Exécutez le test Get-LinkPerformance entre VM1 et VM2. Ce test fournit des informations sur la localisation du problème. Si le 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 le 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 exclu, effectuez des tests similaires sur votre réseau d’entreprise. Si ces tests sont également bons, collaborez avec votre fournisseur d’accès ou fournisseur de services Internet pour diagnostiquer votre connexion WAN. Par exemple, exécuter des tests entre deux succursales, ou entre votre bureau et un serveur de centre de données. Recherchez des points de terminaison tels que les serveurs et les PC clients qui peuvent utiliser le chemin que vous testez.

Important

Pour chaque test, marquez l’heure du jour et enregistrez les résultats dans un emplacement commun. Chaque exécution de test doit avoir une sortie identique pour une comparaison de données cohérente. L’importance de la cohérence entre les différents tests est la raison principale d’utiliser la boîte à outils AzureCT pour la résolution des problèmes. Le plus important est d’obtenir des résultats cohérents de test et de données chaque fois. L’enregistrement de l’heure et la cohérence des données sont particulièrement utiles si le problème est sporadique. Soyez diligent dans la collecte de données en amont pour éviter de passer des heures à tester à nouveau les mêmes scénarios.

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 des problèmes. Par exemple, vous pouvez constater que la liaison via votre fournisseur de services emprunte des tronçons en Europe, alors qu’elle est censée se trouver en Asie. À ce stade, recrutez quelqu’un pour obtenir de l’aide en fonction du domaine de routage vers lequel vous avez isolé le problème. Le limiter à un composant spécifique 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.

Pour les problèmes de réseau étendu, partagez vos résultats de test avec votre fournisseur d’accès ou votre fournisseur de services Internet pour les aider dans leur travail et éviter les tâches redondantes. Ils peuvent souhaiter vérifier vos résultats en fonction du principe « Faites confiance, mais vérifiez ».

Pour les problèmes Azure, une fois que vous isolez le problème de manière aussi détaillée que possible, passez en revue la Documentation réseau Azure et, si nécessaire, ouvrez un ticket de support.

Références

Attentes en termes de latence et de bande passante

Conseil

La distance géographique entre les points de terminaison est le facteur le plus important de la latence. Bien que la latence de l’équipement (composants physiques et virtuels, nombre de tronçons, etc.) joue également un rôle, c’est la distance en fibre optique, et non la distance à vol d’oiseau, qui est le principal facteur. Cette distance est difficile à mesurer avec précision, donc nous utilisons souvent une calculatrice de distance de ville pour une estimation approximative.

Par exemple, nous avons configuré ExpressRoute à Seattle, Washington, États-Unis. Le tableau ci-dessous montre la latence et la bande passante observées lors du test sur différents emplacements Azure, ainsi que les distances estimées.

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 de 10 Gbits/s avec 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, à l’aide de l’image Azure par défaut avec la boîte à outils AzureCT installée.

  • Tous les tests ont utilisé la commande Get-LinkPerformance de la boîte à outils AzureCT, avec 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, le flux de données provient du serveur local (client iPerf à Seattle) vers la machine virtuelle Azure (serveur iPerf dans la région Azure répertoriée).

  • La colonne « Latence » affiche les données du test avec absence de charge (test de latence TCP sans exécution d’iPerf).

  • La colonne « Bande passante maximale » affiche les données du test de charge de 16 flux TCP avec une taille de fenêtre de 1 Mo.

Diagramme de l’environnement de test dans lequel AzureCT est installé.

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 généralement cohérentes au fil du temps, les conditions au sein d’Azure ou du réseau du fournisseur de services peuvent changer, ce qui affecte la latence et la bande passante. En règle générale, ces modifications n’entraînent pas de différences significatives.

Emplacement ExpressRoute Région Azure Distance estimée (km) Latence 1 bande passante de session Bande passante maximale
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 exemple où la distance en fibre optique diffère considérablement de la distance à vol d’oiseau. La latence attendue serait d’environ 160 ms, mais elle est en fait de 189 ms en raison de l’itinéraire en fibre plus long.

Remarque

Ces chiffres ont été testés à l’aide de la boîte à outils AzureCT basée sur iPerf dans Windows via PowerShell. iPerf ne respecte pas les options TCP Windows par défaut du facteur de mise à l’échelle, mais utilise un nombre de décalages plus faible pour obtenir la taille de la fenêtre TCP. En paramétrant les commandes iPerf avec le commutateur -w et une plus grande taille de fenêtre TCP, un meilleur débit peut être atteint. L’exécution d’iPerf en mode multithread à partir de plusieurs machines peut également aider à atteindre le niveau de performance maximal des liens. 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