Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Cet article présente les techniques courantes d'optimisation des performances TCP/IP et certains éléments à prendre en compte lorsque vous les utilisez pour les machines virtuelles exécutées sur Azure. Il fournit une vue d’ensemble de base des techniques et explore la façon dont les machines virtuelles peuvent être paramétrées.
Techniques courantes d’optimisation TCP/IP
MTU, fragmentation et déchargement d’envoi important
MTU
L’unité de transmission maximale (MTU) est la trame de taille la plus grande (paquets plus en-têtes d’accès réseau) spécifiée en octets pouvant être envoyées via une interface réseau. La MTU est un paramètre configurable. La MTU par défaut utilisée sur les machines virtuelles Azure, et le paramètre par défaut sur la plupart des périphériques réseau dans le monde, est de 1 500 octets.
Fragmentation
La fragmentation survient lorsqu'un paquet envoyé dépasse la MTU d'une interface réseau. La pile TCP/IP divise le paquet en morceaux plus petits qui respectent le MTU de l'interface. La fragmentation se produit au niveau de la couche IP et est indépendante du protocole sous-jacent (par exemple TCP). Lorsqu’un paquet de 2 000 octets est envoyé sur une interface réseau avec un MTU de 1 500 octets, le paquet est divisé en un paquet de 1 500 octets et un paquet de 500 octets.
Les périphériques réseau dans le chemin qui sépare une source et une destination peuvent soit supprimer des paquets qui dépassent la MTU, soit fragmenter le paquet en plus petits morceaux.
Bit Ne pas fragmenter d’un paquet IP
Le bit Ne pas fragmenter (Don’t Fragment, DF) représente un drapeau dans l'en-tête du protocole IP. Le bit DF indique que les périphériques réseau sur le chemin entre l'émetteur et le récepteur ne doivent pas fragmenter le paquet. Ce bit peut être défini pour de nombreuses raisons. (Voir la section « Détection MTU du chemin d'accès » de cet article pour visualiser un exemple). Lorsqu'un périphérique réseau reçoit un paquet avec le bit Ne pas fragmenter défini et que ce paquet dépasse la MTU de l'interface du périphérique, le comportement standard veut que le périphérique supprime le paquet. L'appareil envoie un message « ICMP Fragmentation Needed » (Fragmentation ICMP requise) à la source originale du paquet.
Impact de la fragmentation sur les performances
La fragmentation peut avoir des répercussions négatives sur les performances. L’une des principales raisons de l’effet sur les performances est l’effet processeur/mémoire de la fragmentation et de la réassemblage des paquets. Lorsqu’un appareil réseau doit fragmenter un paquet, il doit allouer des ressources processeur/mémoire pour effectuer une fragmentation.
La même chose se produit lorsque le paquet est réassemblé. Le périphérique réseau doit stocker tous les fragments jusqu'à ce qu'il les reçoive afin de pouvoir les réassembler dans le paquet d'origine.
Azure et la fragmentation
Azure ne traite pas les paquets fragmentés avec la mise en réseau accélérée. Lorsqu’une machine virtuelle reçoit un paquet fragmenté, le chemin non accéléré le traite. Par conséquent, les paquets fragmentés manquent les avantages de la mise en réseau accélérée, comme une latence inférieure, une gigue réduite et des paquets plus élevés par seconde. Pour cette raison, nous vous recommandons d'éviter la fragmentation si possible.
Azure, par défaut, supprime les paquets fragmentés qui arrivent à la machine virtuelle hors de l’ordre, ce qui signifie que les paquets ne correspondent pas à la séquence de transmission à partir du point de terminaison source. Ce problème peut se produire lorsque les paquets se déplacent sur Internet ou sur d’autres réseaux étendus.
Ajuster la MTU
Vous pouvez améliorer le débit du réseau virtuel interne en augmentant la MTU pour le trafic de votre machine virtuelle. Toutefois, si la machine virtuelle communique avec des destinations en dehors du réseau virtuel qui ont un MTU différent, la fragmentation peut se produire et réduire les performances.
Pour plus d’informations sur la définition du MTU sur des machines virtuelles Azure, consultez Configurer l’unité de transmission maximale (MTU) pour les machines virtuelles dans Azure.
Déchargement d’envoi important
Le déchargement d’envoi important (Large Send Offload ou LSO) peut améliorer les performances du réseau en déchargeant la segmentation des paquets sur l'adaptateur Ethernet. Lorsque l’authentification LSO est activée, la pile TCP/IP crée un paquet TCP volumineux et l’envoie à l’adaptateur Ethernet pour la segmentation avant de le transférer. L’avantage de la segmentation de grande taille (LSO) libère le processeur de segmenter les paquets en tailles conformes à la MTU et de décharger ce traitement sur le matériel d’interface ethernet. Pour en savoir plus sur les avantages de LSO, consultez la rubrique Prise en charge du déchargement d'envoi important.
Lorsque l’authentification unique est activée, les clients Azure peuvent remarquer de grandes tailles d’images pendant les captures de paquets. Ces grandes tailles de trame peuvent amener certains clients à supposer qu'une fragmentation se produit ou qu'une grande MTU est utilisée alors que ce n'est pas le cas. Avec le LSO, l'adaptateur Ethernet peut signaler une taille de segment maximale (MSS) plus grande à la pile TCP/IP pour créer un paquet TCP plus grand. L’adaptateur Ethernet divise ensuite cette trame non segmentée en plusieurs trames plus petites en fonction de son MTU, qui sont visibles dans une capture de paquets effectuée sur la machine virtuelle.
Mise à l'échelle des fenêtres TCP MSS et PMTUD
Taille maximale des segments TCP
La taille maximale des segments TCP (MSS) est un paramètre qui limite la taille des segments TCP, évitant ainsi la fragmentation des paquets TCP. Les systèmes d’exploitation utilisent généralement cette formule pour définir MSS :
MSS = MTU - (IP header size + TCP header size)
L'en-tête IP et l'en-tête TCP sont de 20 octets chacun, soit 40 octets au total. Une interface avec un MTU de 1 500 a un MSS de 1 460. MsS est configurable.
Ce paramètre est validé dans la connexion en trois temps TCP lorsqu'une session TCP est configurée entre une source et une destination. Les deux côtés envoient une valeur MSS, et la valeur la plus faible est utilisée pour la connexion TCP.
Gardez à l'esprit que les MTU de la source et de la destination ne sont pas les seuls facteurs qui déterminent la valeur MSS. Les périphériques réseau intermédiaires, comme les passerelles VPN et notamment la passerelle VPN Azure, peuvent ajuster la MTU indépendamment de la source et de la destination pour assurer des performances réseau optimales.
Détection MTU du chemin d'accès
La MSS est négociée, mais il se peut qu'elle n'indique pas la MSS réelle qui peut être utilisée. D’autres périphériques réseau du chemin d’accès entre la source et la destination peuvent avoir une valeur MTU inférieure à la source et à la destination. Dans ce cas, l’appareil dont le MTU est inférieur au paquet supprime le paquet. L'appareil renvoie un message « ICMP Fragmentation Needed (Type 3, Code 4) » (Fragmentation ICMP requise (type 3, code 4)) contenant sa MTU. Ce message ICMP permet à l'hôte source de réduire la MTU de son chemin de manière appropriée. Ce processus est appelé Détection MTU du chemin d'accès ou PMTUD (Path MTU Discovery).
Le processus PMTUD réduit les performances du réseau en raison de son inefficacité. Quand le MTU d’un chemin d’accès réseau est dépassé, les paquets doivent être retransmis avec un MSS inférieur. Si un pare-feu réseau bloque le message ICMP Fragmentation Nécessaire, l’expéditeur ignore la nécessité de réduire le MSS et retransmet à plusieurs reprises le paquet. Pour cette raison, nous vous déconseillons d’augmenter la machine virtuelle Azure MTU.
VPN et MTU
Si vous utilisez des machines virtuelles qui effectuent l’encapsulation (comme les VPN IPsec), il existe d’autres considérations relatives à la taille des paquets et à la MTU. Les VPN ajoutent d’autres en-têtes aux paquets. Les en-têtes ajoutés augmentent la taille des paquets et nécessitent un MSS plus petit.
Pour Azure, nous vous recommandons de définir la MSS TCP sur 1 350 octets et la MTU de l’interface tunnel sur 1 400 octets. Pour plus d'informations, consultez la page Périphériques VPN et paramètres IPsec/IKE.
Latence, durée des boucles et mise à l'échelle de la fenêtre TCP
Latence et durée des boucles
La vitesse de la lumière détermine la latence du réseau sur un réseau fibre optique. Le temps d’aller-retour (RTT) entre deux périphériques réseau régit le débit réseau TCP.
| Routage | Distance | Durée (unidirectionnel) | RTT |
|---|---|---|---|
| New York à San Francisco | 4 148 km | 21 ms | 42 ms |
| New York à London | 5 585 km | 28 ms | 56 ms |
| New York à Sydney | 15 993 km | 80 ms | 160 ms |
Ce tableau indique la distance en ligne droite entre deux emplacements. Dans les réseaux, la distance est généralement plus longue que la distance en ligne droite. Voici une formule simple pour calculer la RTT minimale en fonction de la vitesse de la lumière :
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Vous pouvez utiliser 200 comme vitesse de propagation. La vitesse de propagation est la distance, en kilomètres, que la lumière se déplace en 1 milliseconde.
Prenons comme exemple la distance de New York à San Francisco. La distance en ligne droite est de 4 148 km. La saisie de cette valeur dans l’équation entraîne l’équation suivante :
Minimum RTT = 2 * (4,148 / 200)
Le résultat de l'équation est exprimé en millisecondes.
Si vous voulez obtenir les meilleures performances réseau, l'option logique consiste à sélectionner les destinations les plus proches les unes des autres. Vous devriez également concevoir votre réseau virtuel en essayant d’optimiser le chemin du trafic et de réduire la latence. Pour plus d’informations, voir la section « Considérations relatives à la conception du réseau » de cet article.
Effets de la latence et de la durée des bouches sur TCP
La durée des boucles a un impact direct sur le débit TCP maximal. Dans le protocole TCP, la taille de la fenêtre est la quantité maximale de trafic qui peut être envoyé via une connexion TCP avant que l’expéditeur ne doit recevoir l’accusé de réception du destinataire. Si le MSS TCP est défini sur 1 460 et que la taille de la fenêtre TCP est définie sur 65 535, l’expéditeur peut envoyer 45 paquets avant l’accusé de réception du destinataire. Si l’expéditeur ne reçoit pas d’accusé de réception, il retransmet les données. Voici la formule :
TCP window size / TCP MSS = packets sent
Dans cet exemple, 65 535 / 1 460 est arrondi à 45.
Cet état « en attente d’accusé de réception », un mécanisme permettant de garantir une livraison fiable des données, est ce qui entraîne l’impact de RTT sur le débit TCP. Plus l’expéditeur attend l’accusé de réception, plus il doit attendre avant d’envoyer plus de données.
Voici la formule pour calculer le débit maximal d'une connexion TCP unique :
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Ce tableau indique le débit maximal en mégaoctets/seconde d'une connexion TCP unique. (Pour une meilleure lisibilité, les mégaoctets sont utilisés comme unité de mesure.)
| Taille de la fenêtre TCP (octets) | Latence RTT (ms) | Débit maximal en mégaoctets/seconde | Débit maximal en mégabits/seconde |
|---|---|---|---|
| 65 535 | 1 | 65,54 | 524,29 |
| 65 535 | 30 | 2.18 | 17,48 |
| 65 535 | soixante | 1,09 | 8,74 |
| 65 535 | 90 | 0.73 | 5,83 |
| 65 535 | 120 | 0.55 | 4,37 |
Si des paquets sont perdus, le débit maximal d’une connexion TCP est réduit pendant que l’expéditeur retransmet les données qu’il a envoyées.
Mise à l’échelle de la fenêtre TCP
La mise à l’échelle des fenêtres TCP est une technique qui augmente dynamiquement la taille de la fenêtre TCP pour permettre l’envoi de données supplémentaires avant l’envoi d’un accusé de réception. Dans l’exemple précédent, 45 paquets seraient envoyés avant qu’un accusé de réception n’ait été requis. Si vous augmentez le nombre de paquets qui peuvent être envoyés avant qu’un accusé de réception soit nécessaire, vous réduisez le nombre de fois qu’un expéditeur attend l’accusé de réception.
Ce tableau illustre ces relations :
| Taille de la fenêtre TCP (octets) | Latence RTT (ms) | Débit maximal en mégaoctets/seconde | Débit maximal en mégabits/seconde |
|---|---|---|---|
| 65 535 | 30 | 2.18 | 17,48 |
| 131 070 | 30 | 4,37 | 34,95 |
| 262 140 | 30 | 8,74 | 69,91 |
| 524 280 | 30 | 17,48 | 139,81 |
Mais la valeur de l'en-tête TCP pour la taille de la fenêtre TCP n'est que de 2 octets, ce qui signifie que la valeur maximale pour une fenêtre de réception est de 65 535 octets. Pour augmenter la taille maximale de la fenêtre, un facteur d'échelle de la fenêtre TCP a été introduit.
Le facteur d'échelle est également un paramètre que vous pouvez configurer dans un système d'exploitation. Voici la formule pour calculer la taille de la fenêtre TCP en utilisant des facteurs d'échelle :
TCP window size = TCP window size in bytes * (2^scale factor)
Voici le calcul pour un facteur d'échelle de fenêtre de 3 octets et une taille de fenêtre de 65 535 octets :
65,535 * (2^3) = 524,280 bytes
Un facteur d'échelle de 14 octets donne une taille de fenêtre TCP de 14 octets (le décalage maximal autorisé). La taille de la fenêtre TCP est de 1 073 725 440 octets (8,5 gigaoctets).
Prise en charge de la mise à l'échelle de la fenêtre TCP
Windows peut définir différents facteurs d'échelle pour différents types de connexion. (Les classes de connexions incluent les centres de données, Internet, etc.) Vous utilisez la commande PowerShell Get-NetTCPConnection pour afficher le type de connexion de mise à l'échelle de la fenêtre :
Get-NetTCPConnection
Vous pouvez utiliser la commande PowerShell Get-NetTCPSetting pour afficher les valeurs de chaque classe :
Get-NetTCPSetting
Vous pouvez définir la taille initiale de la fenêtre TCP et le facteur d'échelle TCP dans Windows en utilisant la commande PowerShell Set-NetTCPSetting. Pour plus d’informations, voir Set-NetTCPSetting.
Set-NetTCPSetting
Les valeurs suivantes sont les paramètres TCP effectifs pour AutoTuningLevel:
| Niveau de Réglage Automatique | Facteur de mise à l’échelle | Multiplicateur de mise à l’échelle | Formule pour calculer la taille maximale de la fenêtre |
|---|---|---|---|
| Désactivé | Aucun | Aucun | Taille de la fenêtre |
| Restreint | 4 | 2^4 | Taille de la fenêtre * (2^4) |
| Très restreinte | 2 | 2^2 | Taille de la fenêtre * (2^2) |
| Normale | 8 | 2^8 | Taille de la fenêtre * (2^8) |
| Expérimental | 14 | 2^14 | Taille de la fenêtre * (2^14) |
Ces paramètres sont les plus susceptibles d'affecter les performances TCP, mais gardez à l'esprit que de nombreux autres facteurs sur Internet, hors du contrôle d’Azure, peuvent également affecter les performances TCP.
Mise en réseau accélérée et mise à l'échelle côté réception
Mise en réseau accélérée
Les fonctions réseau des machines virtuelles sont historiquement exigeantes en ressources processeur au niveau de la machine virtuelle invitée et de l’hyperviseur/hôte. Le processeur hôte traite dans les logiciels tous les paquets qui transitent par l’hôte, y compris l’encapsulation et la décapsulation de réseau virtuel. Plus le trafic transite par l’hôte, plus la charge du processeur est élevée. Si le processeur hôte est occupé avec d’autres opérations qui affectent le débit et la latence du réseau. Azure règle ce problème grâce à la mise en réseau accélérée.
La mise en réseau accélérée offre une latence réseau ultra-faible constante grâce à un matériel programmable interne Azure et à des technologies comme SR-IOV. La mise en réseau accélérée déplace une grande partie de la pile réseau définie par le logiciel Azure des processeurs vers les cartes SmartNIC basées sur FPGA. Cette modification permet aux applications de l'utilisateur final de récupérer des cycles de calcul, réduisant la charge sur la machine virtuelle et diminuant les instabilités et l'incohérence de la latence. En d'autres termes, les performances peuvent être plus déterministes.
La mise en réseau accélérée améliore les performances en permettant à la machine virtuelle invitée de contourner l'hôte et d'établir un chemin de données directement avec la carte SmartNIC de l'hôte. Voici quelques avantages de la mise en réseau accélérée :
Latence plus faible/Nombre supérieur de paquets par seconde (pps) : la suppression du commutateur virtuel du chemin de données évite que les paquets liés au traitement des stratégies séjournent sur l'hôte, ce qui augmente le nombre de paquets pouvant être traités dans la machine virtuelle.
Instabilité réduite : le traitement du commutateur virtuel dépend de la stratégie à appliquer et de la charge de travail du processeur qui effectue le traitement. Le déchargement des stratégies sur le matériel supprime cette variabilité en fournissant des paquets directement à la machine virtuelle, en supprimant l’hôte dans la communication de la machine virtuelle et toutes les interruptions de logiciel et les changements de contexte.
Utilisation réduite du processeur : en contournant le commutateur virtuel de l'hôte, le processeur utilise moins de ressources pour traiter le trafic réseau.
Pour utiliser la mise en réseau accélérée, vous devez l'activer explicitement sur chaque machine virtuelle applicable. Consultez Créer une machine virtuelle Linux avec la mise en réseau accélérée pour obtenir des instructions.
Mise à l'échelle côté réception
La mise à l'échelle côté réception (Receive Side Scaling ou RSS) est une technologie de pilote réseau qui distribue plus efficacement la réception du trafic réseau en répartissant le traitement de réception entre plusieurs processeurs dans un système multiprocesseur. Pour simplifier, RSS permet à un système de traiter plus de trafic reçu en utilisant tous les processeurs disponibles au lieu d'un seul. Pour obtenir des informations plus techniques sur RSS, consultez Introduction à la mise à l'échelle côté réception.
Pour obtenir les meilleures performances lorsque la mise en réseau accélérée est activée sur une machine virtuelle, vous devez activer RSS. RSS peut également offrir des avantages sur les machines virtuelles qui n'utilisent pas la mise en réseau accélérée. Pour un aperçu sur la façon de vérifier si RSS est activé et comment le faire le cas échéant, voir Optimiser le débit du réseau des machines virtuelles Azure.
Assassinat TCP TIME_WAIT et TIME_WAIT
TCP TIME_WAIT est un autre paramètre courant qui a un impact sur les performances du réseau et des applications. Les machines virtuelles occupées ouvrent et ferment fréquemment de nombreux sockets, en tant que clients ou serveurs. Pendant les opérations TCP normales, un socket entre souvent dans l’état TIME_WAIT et reste là pendant une période prolongée. Cet état garantit la remise de toutes les données restantes sur le socket avant sa fermeture. Par conséquent, les piles TCP/IP empêchent généralement la réutilisation du socket en supprimant le paquet TCP SYN du client en mode silencieux.
Vous pouvez configurer la durée pendant laquelle un socket reste à l’état TIME_WAIT. La durée peut aller de 30 secondes à 240 secondes. Les sockets sont une ressource finie et leur disponibilité est configurable. En règle générale, environ 30 000 sockets sont disponibles pour une utilisation à tout moment donné. Si le système consomme tous les sockets disponibles ou si les clients et les serveurs utilisent des paramètres de TIME_WAIT incompatibles, la machine virtuelle peut tenter de réutiliser un socket toujours à l’état TIME_WAIT. Dans ce cas, les nouvelles connexions échouent, car les paquets TCP SYN sont supprimés en mode silencieux.
La valeur de la plage de ports pour les sockets sortants est configurable dans la pile TCP/IP d’un système d’exploitation. C’est également le cas pour les paramètres TCP TIME_WAIT et la réutilisation d’un socket. La modification de ces valeurs peut potentiellement améliorer l'évolutivité. Mais, selon la situation, ces changements pourraient provoquer des problèmes d'interopérabilité. Faites attention si vous modifiez ces valeurs.
Vous pouvez utiliser l'assassinat TIME_WAIT pour résoudre ce problème de mise à l'échelle. L'assassinat TIME_WAIT permet de réutiliser un socket dans certaines situations, comme lorsque le numéro de séquence dans le paquet IP de la nouvelle connexion dépasse le numéro de séquence du dernier paquet de la connexion précédente. Dans ce cas, le système d’exploitation permet d’établir la nouvelle connexion (elle accepte le nouveau SYN/ACK) et de forcer la fermeture de la connexion précédente dans un état TIME_WAIT. Cette capacité est prise en charge sur les machines virtuelles Windows dans Azure. Pour en savoir plus sur la prise en charge dans d'autres machines virtuelles, contactez l’éditeur du système d'exploitation.
Pour en savoir plus sur la configuration des paramètres TCP TIME_WAIT et la plage de ports source, voir Paramètres pouvant être modifiés pour améliorer les performances du réseau.
Facteurs du réseau virtuel pouvant affecter les performances
Débit sortant maximal de la machine virtuelle
Azure fournit différentes tailles et types de machines virtuelles, chacun avec une combinaison différente de fonctionnalités de performances. Une de ces capacités est le débit réseau (ou bande passante), mesurée en mégabits par seconde (Mbit/s). Étant donné que les machines virtuelles sont hébergées sur du matériel partagé, la capacité du réseau doit être répartie équitablement entre les machines virtuelles partageant le même matériel. Les machines virtuelles plus volumineuses bénéficient d’une plus grande bande passante que les machines plus petites.
La bande passante réseau allouée à chaque machine virtuelle est mesurée sur le trafic sortant (sortant) de la machine virtuelle. L’ensemble du trafic réseau quittant la machine virtuelle est mesuré en fonction de la limite d’allocation, quelle que soit la destination. Si une machine virtuelle a une limite de 1 000 Mbits/s, cette limite s’applique si le trafic sortant est destiné à une autre machine virtuelle dans le même réseau virtuel ou en dehors d’Azure.
L’afflux n’est pas mesuré ou limité directement. Mais il existe d’autres facteurs, tels que les limites en termes de processeur et de stockage, susceptibles d’affecter la capacité d’une machine virtuelle à traiter les données entrantes.
La mise en réseau accélérée est conçue pour améliorer les performances du réseau, notamment la latence, le débit et le taux d’utilisation des processeurs. La mise en réseau accélérée peut améliorer le débit de la machine virtuelle, mais en deçà de la limite de bande passante allouée à la machine virtuelle.
Les machines virtuelles Azure doivent toujours être associées à au moins une interface réseau. Il peut y en avoir plusieurs. La bande passante allouée à une machine virtuelle représente l’intégralité du trafic sortant sur l’ensemble des interfaces réseau associées à la machine. En d’autres termes, la bande passante est allouée machine virtuelle par machine virtuelle, quel que soit le nombre d’interfaces réseau associées à cette machine.
Le débit sortant attendu et le nombre d’interfaces réseau prises en charge par chaque taille de machine virtuelle sont détaillés dans la section Tailles des machines virtuelles Windows dans Azure. Pour afficher le débit maximal, sélectionnez un type, par exemple Usage général, puis recherchez la section consacrée aux séries de tailles sur la page résultante (par exemple, « Série Dv2 »). Pour chaque série, un tableau fournit les spécifications réseau dans la dernière colonne, sous le titre « Nombre max de cartes réseau / Bande passante réseau attendue (Mbit/s) ».
Cette limite de débit s’applique à la machine virtuelle. Le débit n’est pas affecté par ces facteurs :
Nombre d'interfaces réseau : La limite de bande passante s’applique à l’ensemble du trafic sortant en provenance de la machine virtuelle.
Mise en réseau accélérée : bien que cette fonctionnalité puisse être utile pour atteindre la limite publiée, elle ne modifie pas cette limite.
Destination du trafic : toutes les destinations s’inscrivent dans la limite de sortie.
Protocole : L’intégralité du trafic sortant, sur l’ensemble des protocoles, s’inscrit dans la limite.
Pour plus d’informations, consultez Bande passante réseau des machines virtuelles.
Optimisation des machines virtuelles Linux
Les noyaux Linux modernes ont des fonctionnalités qui peuvent aider à atteindre la cohérence et les performances, parfois requises par certaines charges de travail.
Pour plus d’informations, consultez Optimiser la bande passante réseau sur les machines virtuelles Azure
Considérations relatives aux performances Internet
Comme expliqué tout au long de cet article, des facteurs sur Internet et hors du contrôle d'Azure peuvent affecter les performances du réseau. Voici quelques-uns de ces facteurs :
Latence : le temps d’aller-retour entre deux points de terminaison est affecté par des problèmes sur les réseaux intermédiaires, par le trafic qui ne prend pas le chemin de distance le plus court et par des chemins d’accès de peering non optimaux.
Perte de paquets : la perte de paquets est due à la congestion du réseau, aux problèmes de chemin d’accès physique et aux périphériques réseau sous-performants.
Taille de MTU/fragmentation : La fragmentation le long du chemin peut entraîner des retards dans la réception des données ou une réception de paquets en désordre, ce qui peut affecter la remise des paquets.
Traceroute est un bon outil pour mesurer les performances du réseau (notamment la perte de paquets et la latence) le long de chaque chemin réseau entre un périphérique source et un périphérique cible.
Considérations relatives à la conception du réseau
Outre les considérations abordées précédemment dans cet article, la topologie d'un réseau virtuel peut affecter les performances du réseau. Par exemple, une conception « hub-and-spoke » qui renvoie le trafic mondial vers un réseau virtuel à un seul concentrateur entraîne une latence du réseau, ce qui affecte ses performances globales.
Le nombre de périphériques réseau par lesquels le trafic réseau transite peut également affecter la latence globale. Par exemple, dans une conception hub-and-spoke, si le trafic transite via une appliance virtuelle réseau spoke et une appliance virtuelle hub avant d’être dirigé vers Internet, les appliances virtuelles réseau peuvent entraîner une latence.
Régions Azure, réseaux virtuels et latence
Les régions Azure sont composées de plusieurs centres de données qui existent dans une zone géographique générale. Ces centres de données peuvent ne pas être physiquement adjacents. Dans certains cas, ils sont séparés par autant que 10 kilomètres. Le réseau virtuel est une superposition logique sur le réseau du centre de données physique Azure. Un réseau virtuel n'implique aucune topologie de réseau spécifique au sein du centre de données.
Par exemple, deux machines virtuelles figurant dans le même réseau virtuel et le même sous-réseau peuvent se trouver dans des racks, des lignes ou même des centres de données différents. Ils peuvent être séparés par pieds de câble fibre optique ou par kilomètres de câble fibre optique. Cette variation pourrait entraîner une latence variable (une différence de quelques millisecondes) entre différentes machines virtuelles.
Le positionnement géographique des machines virtuelles et la latence potentielle résultante entre deux machines virtuelles est influencé par la configuration des groupes à haute disponibilité, des groupes de placement de proximité et des zones de disponibilité. Mais la distance entre les centres de données d'une région est spécifique à cette région et elle est principalement influencée par la topologie des centres de données de cette région.
Épuisement du port NAT source
Un déploiement dans Azure peut communiquer avec des points de terminaison en dehors d’Azure sur le réseau Internet public et/dans l’espace d’adressage IP public. Quand une instance démarre une connexion sortante, Azure mappe dynamiquement l’adresse IP privée à une adresse IP publique. Une fois ce mappage créé, le trafic de retour pour le flux sortant peut aussi atteindre l’adresse IP privée d’où provient le flux.
Pour chaque connexion sortante, Azure Load Balancer doit maintenir ce mappage pendant un certain temps. Étant donné la nature multilocataire d'Azure, le maintien de ce mappage pour chaque flux sortant de chaque machine virtuelle peut consommer beaucoup de ressources. Il existe donc des limites fixées et basées sur la configuration du réseau virtuel Azure. Ou, pour dire que plus précisément, une machine virtuelle Azure peut uniquement établir des connexions sortantes à un moment donné. Lorsque ces limites sont atteintes, la machine virtuelle n’effectue pas de connexions sortantes supplémentaires.
Mais ce comportement est configurable. Pour plus d'informations sur SNAT et l'épuisement de port SNAT, consultez cet article.
Mesurer les performances du réseau sur Azure
La plupart des maximums de performances de cet article sont liés à la latence réseau / temps d’aller-retour (RTT) entre deux machines virtuelles. Cette section fournit quelques suggestions sur la façon de tester la latence/RTT et les performances TCP et des machines virtuelles du réseau. Vous pouvez régler les valeurs TCP/IP et réseau et tester leurs performances, comme discuté précédemment, en utilisant les techniques décrites dans cette section. Entrez la latence, MTU, MSS et les valeurs de taille de fenêtre dans les calculs fournis précédemment et comparez les maximums théoriques aux valeurs réelles observées pendant le test.
Mesurer la durée des bouches (RTT) et la perte de paquets
Les performances TCP dépendent fortement de RTT et de la perte de paquets. L'utilitaire PING disponible sur Windows et Linux fournit le moyen le plus simple de mesurer la durée RTT et la perte de paquets. La sortie de PING affiche la latence minimale/maximale/moyenne entre une source et une destination. Cela indique une perte de paquets. PING utilise le protocole ICMP par défaut. Vous pouvez utiliser PsPing pour tester TCP RTT. Pour plus d'informations, consultez PsPing.
Les pings ICMP et TCP ne mesurent pas le chemin de données réseau accéléré. Pour mesurer le chemin de données, consultez Latte et SockPerf dans cet article.
Mesurer la bande passante réelle d'une machine virtuelle
Pour mesurer avec précision la bande passante des machines virtuelles Azure, suivez ces conseils.
Pour plus d’informations sur le test d’autres scénarios, consultez les articles suivants :
Détecter les comportements TCP inefficaces
Dans les captures de paquets, les clients Azure peuvent voir des paquets TCP avec des indicateurs TCP (SACK, DUP ACK, RETRANSMIT et FAST RETRANSMIT) qui pourraient signaler des problèmes de performance réseau. Ces paquets indiquent spécifiquement les problèmes réseau qui résultent de la perte de paquets. Mais la perte de paquets n'est pas nécessairement causée par des problèmes de performance Azure. Les problèmes de performances peuvent être dus à l’application, au système d’exploitation ou à d’autres problèmes qui ne sont peut-être pas directement liés à la plateforme Azure.
Sans oublier que certains événements ACK de retransmission et de duplication sont normaux sur un réseau. Les protocoles TCP ont été conçus pour être fiables. La présence de ces paquets TCP dans une capture de paquets n'indique pas nécessairement un problème de réseau systémique, à moins que leur nombre soit excessif.
Néanmoins, ces types de paquets sont des indications que le débit TCP n'atteint pas ses performances maximales, pour les raisons discutées dans d’autres sections de cet article.
Étapes suivantes
Maintenant que vous avez découvert le réglage des performances TCP/IP pour les machines virtuelles Azure, envisagez d’explorer d’autres facteurs pour planifier des réseaux virtuels. Vous pouvez également en savoir plus sur la connexion et la configuration des réseaux virtuels.