Optimiser le débit du réseau des machines virtuelles Azure

Azure machines virtuelles ont des paramètres réseau par défaut qui peuvent être optimisés pour améliorer le débit et la cohérence. Cet article explique comment optimiser les performances réseau pour les machines virtuelles Windows et Linux.

Important

La plupart des optimisations décrites dans cet article (par exemple, le contrôle de congestion, la discipline de file d’attente, les tailles de mémoire tampon et le réglage de la carte réseau) affectent la façon dont le trafic circule entre les systèmes.

Pour obtenir de meilleurs résultats, appliquez ces paramètres de manière cohérente sur toutes les machines virtuelles participant à la charge de travail, notamment :

  • Systèmes clients
  • Systèmes serveur

L’application de ces configurations à un sous-ensemble de machines virtuelles uniquement peut entraîner :

  • Débit incohérent
  • Retransmissions de paquets accrues
  • Comportement de congestion non optimal

Validez toujours les modifications sur l’ensemble du chemin de données et testez les performances de bout en bout.

Machines virtuelles Windows

Si votre machine virtuelle Windows prend en charge la mise en réseau accélérée, activez cette fonctionnalité pour un débit optimal. Pour plus d’informations, consultez l’article Créer une machine virtuelle avec les performances réseau accélérées.

Pour toutes les autres machines virtuelles Windows, la mise à l’échelle côté réception (RSS) peut fournir un débit maximal supérieur à celui d’une machine virtuelle sans RSS. Rss peut être désactivé par défaut. Pour vérifier si RSS est activé et l’activer, procédez comme suit :

  1. Vérifiez si RSS est activé pour une carte réseau à l'aide de la commande PowerShell Get-NetAdapterRss. Dans l’exemple suivant, la sortie de Get-NetAdapterRss indique que RSS n’est pas activé.

    Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False

  2. Pour activer RSS, entrez la commande suivante :

    Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}

    Cette commande n’a pas de sortie. Il modifie les paramètres de carte d’interface réseau et provoque une perte de connectivité temporaire pendant environ une minute. Une boîte de dialogue de reconnexion s’affiche lors de la perte de connectivité. En général, la connectivité est rétablie après la troisième tentative.

  3. Vérifiez que la mise à l’échelle côté réception (RSS) est activée sur la machine virtuelle en entrant de nouveau la commande Get-NetAdapterRss. Si l’opération réussit, l’exemple de sortie suivant est retourné :

    Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True

Machines virtuelles Linux

RSS est activé par défaut dans les machines virtuelles Linux dans Azure. Les noyaux Linux publiés depuis octobre 2017 incluent des options d’optimisation réseau supplémentaires qui aident les machines virtuelles Linux à obtenir un débit plus élevé.

Activer la mise en réseau accélérée Azure pour un débit optimal

Azure Accelerated Networking peut considérablement améliorer le débit et réduire la latence et la gigue. En fonction de la taille de machine virtuelle et de la génération de plateforme, Azure utilise l’une des deux technologies : Mellanox, qui est largement disponible et MANA, développée par Microsoft.

Noyaux Azure optimisés

Certaines distributions, telles que Ubuntu (Canonical) et SUSE, fournissent Azure noyaux paramétrés.

Utilisez la commande suivante pour vérifier que vous utilisez le noyau Azure, qui inclut azure généralement le nom du noyau.

uname -r

# Sample output for an Azure kernel on an Ubuntu Linux VM
6.8.0-1017-azure

Autres distributions Linux

La plupart des distributions modernes incluent des améliorations majeures de la mise en réseau dans les noyaux plus récents. Vérifiez votre version du noyau et utilisez la version 4.19 ou ultérieure si possible. Les noyaux plus récents incluent un meilleur comportement réseau et prennent en charge les options modernes de contrôle de congestion telles que BBR.

Atteindre des vitesses de transfert cohérentes dans des machines virtuelles Linux dans Azure

Les machines virtuelles Linux peuvent afficher des vitesses de transfert incohérentes, en particulier pendant les transferts régionaux volumineux (par exemple, 1 Go à 50 Go entre l’Europe Ouest et usa Ouest). Les causes courantes incluent des noyaux plus anciens, des tailles de mémoire tampon par défaut et des paramètres de contrôle de congestion non réglés ou de discipline de file d’attente.

Pour obtenir un débit plus cohérent, appliquez le réglage de référence suivant, puis testez les combinaisons congestion/qdisc pour votre charge de travail.

Réglage sysctl de référence (copier/coller)

Appliquez les paramètres sysctl de référence suivants :

sudo tee /etc/sysctl.d/99-azure-network-tuning.conf > /dev/null <<'EOF'
# Buffer and memory tuning
# Overall TCP memory pressure thresholds (min, pressure, max pages)
net.ipv4.tcp_mem = 4096 87380 67108864
# Overall UDP memory pressure thresholds (min, pressure, max pages)
net.ipv4.udp_mem = 4096 87380 33554432
# Per-socket TCP read buffer limits (min, default, max bytes)
net.ipv4.tcp_rmem = 4096 87380 67108864
# Per-socket TCP write buffer limits (min, default, max bytes)
net.ipv4.tcp_wmem = 4096 65536 67108864
# Default socket receive buffer size in bytes
net.core.rmem_default = 33554432
# Default socket send buffer size in bytes
net.core.wmem_default = 33554432
# Minimum UDP send buffer per socket in bytes
net.ipv4.udp_wmem_min = 16384
# Minimum UDP receive buffer per socket in bytes
net.ipv4.udp_rmem_min = 16384
# Maximum socket send buffer size in bytes
net.core.wmem_max = 134217728
# Maximum socket receive buffer size in bytes
net.core.rmem_max = 134217728
# Busy polling time in microseconds for low-latency packet receive
net.core.busy_poll = 50
# Busy read time in microseconds when polling sockets
net.core.busy_read = 50

# Extra TCP and networking settings
# Enable TCP timestamps for RTT measurement and PAWS protection
net.ipv4.tcp_timestamps = 1
# Allow safer TIME-WAIT socket reuse for outbound connections
net.ipv4.tcp_tw_reuse = 1
# Expand available ephemeral source port range
net.ipv4.ip_local_port_range = 1024 65535
# Increase packets processed per NAPI polling cycle
net.core.netdev_budget = 1000
# Increase per-socket ancillary/option memory limit in bytes
net.core.optmem_max = 65535
# Disable F-RTO (typically unnecessary on stable wired paths)
net.ipv4.tcp_frto = 0
# Increase maximum listen backlog for pending connections
net.core.somaxconn = 32768
# Increase ingress packet backlog queue length
net.core.netdev_max_backlog = 32768
# Increase per-CPU packet processing quota per softirq cycle
net.core.dev_weight = 64
EOF

sudo sysctl --system

Contrôle de congestion et tests de qdisc (sysctl)

Différentes charges de travail se comportent différemment. Testez ces combinaisons et conservez celle qui donne les meilleurs résultats pour votre profil de latence, de débit et de retransmission.

  1. BBR + FQ (souvent forte valeur par défaut pour les transferts à débit élevé et long-courrier) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
  2. BBR + PFIFO_FAST (utile pour comparer le comportement de la file d’attente en présence d’un trafic en rafales ou mixte) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast
  3. CUBE + PFIFO_FAST (base de référence héritée commune pour la compatibilité et la comparaison) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast

Mesurez chaque option avec le trafic représentatif, puis utilisez la combinaison la plus performante pour votre environnement.

Note

pfifo_fast la disponibilité peut varier en fonction de la distribution/du noyau. S’il n’est pas disponible, utilisez l’option qdisc la plus proche prise en charge dans votre environnement et poursuivez l’évaluation.

Règle UDEV pour les mémoires tampons en anneau de carte réseau (TX/RX)

Créez une règle udev dans /etc/udev/rules.d/99-azure-ring-buffer.rules pour appliquer les paramètres du tampon circulaire aux interfaces réseau :

Utiliser rx 4096 tx 4096 pour les interfaces réseau accélérées (hv_pci) et conserver rx 1024 tx 1024 pour les interfaces synthétiques hv_netvsc .

Si vous préférez une approche interactive pour le réglage du tampon circulaire, vous pouvez également utiliser cet outil d’aide : Configuration de la carte réseau Azure Linux (bash).

Note

Cet outil GitHub est une aide facultative et ne fait pas partie de la documentation produit de Microsoft Learn. Passez en revue les scripts et testez les modifications dans un environnement hors production avant le déploiement étendu.

# Setup Accelerated Interface ring buffers (Mellanox / Mana) 
SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 4096 tx 4096"

# Setup Synthetic interface ring buffers (hv_netvsc)
SUBSYSTEM=="net", DRIVERS=="hv_netvsc*", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 1024 tx 1024"

Règle UDEV pour qdisc sur les événements d’interface

Une fois les tests de performances terminés et le qdisc de votre choix sélectionné, créez une règle udev dans /etc/udev/rules.d/99-azure-qdisc.rules pour appliquer ce qdisc lorsque des interfaces réseau sont ajoutées ou modifiées.

Remplacez <qdisc_choice> par le qdisc que vous avez sélectionné lors du test (par exemple, fq ou pfifo_fast) :

ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="enp*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root noqueue"
ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="eth*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root <qdisc_choice>"

Règle UDEV pour la longueur de la file d'attente d'émission de l'interface réseau

Créez la règle /etc/udev/rules.d/99-azure-txqueue-len.rules suivante pour augmenter la longueur de la file d’attente de transmission :

SUBSYSTEM=="net", ACTION=="add|change", KERNEL=="eth*", ATTR{tx_queue_len}="10000"

Ordonnancement des IRQ (irqbalance)

Selon votre charge de travail, vous souhaiterez peut-être empêcher le service irqbalance de planifier les IRQ sur certains nœuds. Lorsque vous utilisez IRQBalance, mettez à jour /etc/default/irqbalance pour indiquer quels processeurs ne doivent pas se voir attribuer d’IRQ. Vous devez déterminer le masque qui exclut ces PROCESSEURs.

Vous trouverez plus d’informations sur la façon de calculer le masque ici.

SR-IOV comportement à double interface et effets secondaires

Dans la mise en réseau haute performance Linux, Azure utilise SR-IOV (par exemple, avec des pilotes Mellanox tels que mlx4 ou mlx5). Dans ce modèle, vous pouvez voir à la fois une interface synthétique et une interface de fonction virtuelle (VF) pour le même chemin de mise en réseau de machine virtuelle. En savoir plus.

Cette conception est attendue, mais elle peut créer une confusion lors du réglage et de la résolution des problèmes si les deux interfaces sont traitées comme des chemins de données indépendants.

Les effets secondaires possibles sont les suivants :

  • Résultats de benchmark incohérents lorsque les paramètres sont appliqués à une interface, mais que le trafic utilise l’autre.
  • Pics de latence ou retransmissions inattendus lors du basculement entre les chemins synthétiques et VF.
  • Diagnostics trompeurs si les compteurs et les captures de paquets sont collectés à partir de l’interface incorrecte.

Pour réduire les risques :

  • Vérifiez l’interface qui transporte votre trafic de charge de travail avant le réglage.
  • Gardez le réglage udev et sysctl cohérents avec votre stratégie d’interface.
  • Testez à nouveau le débit et la latence après le redémarrage, les mises à jour du pilote ou les modifications d’état réseau accélérées.

Notes supplémentaires

Les administrateurs système peuvent implémenter ces recommandations en modifiant des fichiers de configuration tels que /etc/sysctl.d/, /etc/modules-load.d/et /etc/udev/rules.d/. Passez en revue attentivement les mises à jour du noyau et du pilote pour éviter les régressions.

Pour plus d’informations sur les configurations et la résolution des problèmes spécifiques, consultez Azure documentation sur les performances réseau.

Contenu connexe

  • Last updated on