Partager via


Fonctionnement des performances réseau accélérées dans les machines virtuelles Linux et FreeBSD

Lorsqu'une machine virtuelle (VM) est créée dans Azure, une interface réseau synthétique est créée pour chaque carte réseau virtuelle dans sa configuration. L’interface synthétique est un appareil VMbus et utilise le pilote « netvsc ». Les paquets réseau qui utilisent cette interface synthétique circulent dans le commutateur virtuel de l’hôte Azure et sur le réseau physique du centre de données.

Si la VM est configurée avec Accelerated Networking, une deuxième interface réseau est créée pour chaque carte réseau virtuelle configurée. La seconde interface est une fonction virtuelle SR-IOV (VF) offerte par la carte réseau physique de l'hôte Azure. L'interface VF apparaît dans l'invité Linux comme un périphérique PCI. Elle utilise le pilote Mellanox mlx4 ou mlx5 dans Linux, car les hôtes Azure utilisent des cartes réseau physiques de Mellanox.

La plupart des paquets réseau sont directement placés entre l’invité Linux et la carte réseau physique sans traverser le commutateur virtuel ni un autre logiciel qui s’exécute sur l’ordinateur hôte. En raison de l’accès direct au matériel, la latence du réseau est plus faible et moins de temps processeur est utilisé pour traiter les paquets réseau par rapport à l’interface synthétique.

Différents hôtes Azure utilisent différents modèles de carte réseau physique Mellanox. Linux détermine automatiquement s’il faut utiliser le pilote « mlx4 » ou « mlx5 ». L’infrastructure Azure contrôle l’emplacement de la machine virtuelle sur l’hôte Azure. Si aucune option client ne spécifie la carte réseau physique qui doit être utilisée par un déploiement de machine virtuelle, les machines virtuelles doivent inclure les deux pilotes. Si une machine virtuelle est arrêtée/libérée, puis redémarrée, elle peut être redéployée sur du matériel avec un autre modèle de carte réseau physique Mellanox. Par conséquent, la machine virtuelle peut utiliser l’autre pilote Mellanox.

Si une image de machine virtuelle n’inclut pas de pilote pour la carte réseau physique Mellanox, les fonctionnalités réseau continuent de fonctionner à des vitesses plus lentes de la carte réseau virtuelle. Le portail, Azure CLI et Azure PowerShell affichent la fonctionnalité Performances réseau accélérées comme étant activée.

FreeBSD offre la même prise en charge des performances réseau accélérées que Linux lors de l’exécution dans Azure. Le reste de cet article décrit Linux et utilise des exemples Linux, mais les mêmes fonctionnalités sont disponibles dans FreeBSD.

Notes

Cet article contient des références au terme esclave, un terme que Microsoft n’utilise plus. Lorsque ce terme sera supprimé du logiciel, nous le supprimerons de cet article.

Agrégation de liens (bonding)

L’interface réseau synthétique et l’interface VF sont appairées automatiquement et agissent comme une interface unique dans la plupart des aspects utilisés par les applications. Le pilote netvsc effectue la liaison. Selon la distribution Linux, les règles et les scripts udev peuvent aider à nommer l'interface VF et à configurer le réseau.

Si la machine virtuelle est configurée avec plusieurs cartes réseau virtuelles, l’hôte Azure fournit un numéro de série unique pour chacune d’entre elles. Il permet à Linux d'associer correctement les interfaces synthétiques et VF pour chaque carte d'interface virtuelle.

Les interfaces synthétiques et VF ont la même adresse MAC. Ensemble, elles constituent une carte réseau unique du point de vue des autres entités réseau qui échangent des paquets avec la carte réseau virtuelle dans la machine virtuelle. Les autres entités n’effectuent aucune action spéciale en raison de l’existence de l’interface synthétique et de l’interface VF.

Les deux interfaces sont visibles via la commande ifconfig ou ip addr dans Linux. Voici un exemple de sortie de ifconfig :

U1804:~$ ifconfig
enP53091s1np0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
ether 00:0d:3a:f5:76:bd  txqueuelen 1000  (Ethernet)
RX packets 365849  bytes 413711297 (413.7 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 9447684  bytes 2206536829 (2.2 GB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.1.19.4  netmask 255.255.255.0  broadcast 10.1.19.255
inet6 fe80::20d:3aff:fef5:76bd  prefixlen 64  scopeid 0x20<link>
ether 00:0d:3a:f5:76:bd  txqueuelen 1000  (Ethernet)
RX packets 8714212  bytes 4954919874 (4.9 GB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 9103233  bytes 2183731687 (2.1 GB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

L'interface synthétique porte toujours un nom de la forme eth\<n\>. Selon la distribution Linux, l’interface VF peut avoir un nom au format eth\<n\>. Il peut également avoir un nom différent sous la forme enP\<n\> en raison d’une règle udev qui effectue un renommage.

Vous pouvez déterminer si une interface particulière est l'interface synthétique ou l'interface VF en utilisant la ligne de commande shell qui indique le pilote de périphérique utilisé par l'interface :

$ ethtool -i <interface name> | grep driver

Si le pilote est hv_netvsc, c’est l’interface synthétique. L’interface VF a un nom de pilote qui contient « mlx ». L’interface VF est également identifiable, car son flags champ inclut SLAVE. Cet indicateur indique qu’il est sous le contrôle de l’interface synthétique qui a la même adresse MAC.

Les adresses IP sont affectées uniquement à l’interface synthétique. La sortie de ifconfig ou ip addr montre également cette distinction.

Utilisation des applications

Les applications doivent interagir uniquement avec l’interface synthétique, comme dans tout autre environnement de mise en réseau. Les paquets réseau sortants sont envoyés du pilote netvsc au pilote VF, puis transmis par le biais de l’interface VF.

Les paquets entrants sont reçus et traités sur l’interface VF avant d’être transmis à l’interface synthétique. Les exceptions sont les paquets TCP SYN entrants et les paquets de diffusion/multidiffusion qui sont traités seulement par l’interface synthétique.

Vous pouvez vérifier que les paquets circulent sur l’interface VF à partir de la sortie de ethtool -S eth\<n\>. Les lignes de la sortie qui contiennent vf montrent le trafic sur l’interface VF. Par exemple :

U1804:~# ethtool -S eth0 | grep ' vf_'
 vf_rx_packets: 111180
 vf_rx_bytes: 395460237
 vf_tx_packets: 9107646
 vf_tx_bytes: 2184786508
 vf_tx_dropped: 0

Si ces compteurs s'incrémentent lors des exécutions successives de la commande ethtool, le trafic réseau circule sur l'interface VF.

Vous pouvez vérifier l’existence de l’interface VF en tant que périphérique PCI à l’aide de la lspci commande . Par exemple, sur la VM de génération 1, vous pouvez obtenir une sortie similaire à la suivante. (Les machines virtuelles de génération 2 n’ont pas les appareils PCI hérités.)

U1804:~# lspci
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03)
0000:00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA
cf63:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80)

Dans cet exemple, la dernière ligne de sortie identifie une fonction VF à partir de la carte réseau physique Mellanox ConnectX-4.

La commande ethtool -l or ethtool -L (pour obtenir et définir le nombre de files d'attente d'émission et de réception) est une exception à la règle d'interaction avec l'interface eth<n>. Cette commande peut être utilisée directement sur l’interface VF pour contrôler le nombre de files d’attente pour l’interface VF. Le nombre de files d’attente pour l’interface VF est indépendant du nombre de files d’attente pour l’interface synthétique.

Interprétation des messages de démarrage

Lors du démarrage, Linux affiche de nombreux messages relatifs à l'initialisation et à la configuration de l'interface VF. Il donne également des informations sur la liaison avec l'interface synthétique. La compréhension de ces messages peut être utile pour identifier les problèmes dans le processus.

Voici un exemple de la sortie de la commande dmesg, réduite aux lignes pertinentes pour l'interface VF. En fonction de la distribution et de la version du noyau Linux dans votre machine virtuelle, les messages peuvent varier légèrement, mais le flux général reste identique.

[    2.327663] hv_vmbus: registering driver hv_netvsc
[    3.918902] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF slot 1 added

Le pilote netvsc pour eth0 a été enregistré.

[    6.944883] hv_vmbus: registering driver hv_pci

Le pilote PCI VMbus virtuel a été inscrit. Ce pilote fournit des services PCI de base dans une machine virtuelle Linux dans Azure. Vous devez l’inscrire avant que l’interface VF puisse être détectée et configurée.

[    6.945132] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI VMBus probing: Using version 0x10002
[    6.947953] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI host bridge to bus cf63:00
[    6.947955] pci_bus cf63:00: root bus resource [mem 0xfe0000000-0xfe00fffff window]
[    6.948805] pci cf63:00:02.0: [15b3:1016] type 00 class 0x020000
[    6.957487] pci cf63:00:02.0: reg 0x10: [mem 0xfe0000000-0xfe00fffff 64bit pref]
[    7.035464] pci cf63:00:02.0: enabling Extended Tags
[    7.040811] pci cf63:00:02.0: 0.000 Gb/s available PCIe bandwidth, limited by Unknown x0 link at cf63:00:02.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link)
[    7.041264] pci cf63:00:02.0: BAR 0: assigned [mem 0xfe0000000-0xfe00fffff 64bit pref]

L’appareil PCI avec le GUID répertorié (attribué par l’hôte Azure) a été détecté. Il reçoit un ID de domaine PCI (0xcf63 dans le cas présent) en fonction du GUID. L’ID de domaine PCI doit être unique sur tous les appareils PCI disponibles dans la machine virtuelle. Cette exigence d'unicité couvre d'autres interfaces VF Mellanox, des GPU, des périphériques NVMe et d'autres périphériques qui pourraient être présents dans la VM.

[    7.128515] mlx5_core cf63:00:02.0: firmware version: 14.25.8362
[    7.139925] mlx5_core cf63:00:02.0: handle_hca_cap:524:(pid 12): log_max_qp value in current profile is 18, changing it to HCA capability limit (12)
[    7.342391] mlx5_core cf63:00:02.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(256) RxCqeCmprss(0)

Une VF Mellanox utilisant le pilote mlx5 a été détecté. Le pilote mlx5 commence son initialisation de l’appareil.

[    7.465085] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF registering: eth1
[    7.465119] mlx5_core cf63:00:02.0 eth1: joined to eth0

L’interface synthétique correspondante qui utilise le pilote netvsc a détecté un VF correspondant. Le pilote mlx5 reconnaît qu’il a été lié par bonding à l’interface synthétique.

[    7.466064] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in legacy RQ
[    7.480575] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in legacy RQ
[    7.480651] mlx5_core cf63:00:02.0 enP53091s1np0: renamed from eth1

Le noyau Linux a initialement nommé l’interface eth1VF . Une règle udev l’a renommée pour éviter toute confusion avec les noms donnés aux interfaces synthétiques.

[    8.087962] mlx5_core cf63:00:02.0 enP53091s1np0: Link up

L’interface Mellanox VF est désormais opérationnelle et active.

[    8.090127] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched to VF: enP53091s1np0
[    9.654979] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched from VF: enP53091s1np0

Ces messages indiquent que le chemin d’accès aux données de la paire liée a changé pour utiliser l’interface VF. Environ 1,6 seconde plus tard, il revient à l'interface synthétique. Ces commutations peuvent se produire deux ou trois fois au cours du processus de démarrage et constituent un comportement normal lors de l'initialisation de la configuration.

[    9.909128] mlx5_core cf63:00:02.0 enP53091s1np0: Link up
[    9.910595] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched to VF: enP53091s1np0
[   11.411194] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched from VF: enP53091s1np0
[   11.532147] mlx5_core cf63:00:02.0 enP53091s1np0: Disabling LRO, not supported in legacy RQ
[   11.731892] mlx5_core cf63:00:02.0 enP53091s1np0: Link up
[   11.733216] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched to VF: enP53091s1np0

Le message final indique que le chemin des données a changé pour utiliser l’interface VF. Ce comportement est attendu pendant le fonctionnement normal de la machine virtuelle.

Maintenance de l’hôte Azure

Pendant la maintenance de l'hôte Azure, toutes les interfaces VF peuvent être temporairement supprimées de la VM. Une fois la maintenance effectuée, les interfaces VF sont de nouveau ajoutées à la machine virtuelle. Le fonctionnement normal se poursuit. Pendant que la machine virtuelle fonctionne sans les interfaces VF, le trafic réseau continue à circuler via l’interface synthétique sans aucune interruption des applications.

Dans ce contexte, l'entretien de l'hôte Azure peut inclure la mise à jour des composants de l'infrastructure du réseau Azure ou la mise à jour complète du logiciel de l'hyperviseur de l'hôte Azure. Ces événements se produisent à des intervalles de temps qui dépendent des besoins opérationnels de l'infrastructure Azure. Ces événements se produisent généralement plusieurs fois au cours d'une année.

La commutation automatique entre l’interface VF et l’interface synthétique garantit que les événements de maintenance ne perturbent pas les charges de travail si les applications interagissent seulement avec l’interface synthétique. Les latences et la charge du processeur peuvent être plus élevées pendant ces périodes en raison de l’utilisation de l’interface synthétique. La durée de ces périodes est généralement d'environ 30 secondes, mais peut parfois atteindre quelques minutes.

Le retrait et la lecture de l'interface VF au cours d'un événement de maintenance sont visibles dans la sortie dmesg de la VM. Voici une sortie standard :

[   8160.911509] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched from VF: enP53091s1np0
[   8160.912120] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF unregistering: enP53091s1np0
[   8162.020138] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF slot 1 removed

Le chemin d’accès aux données n’indique plus l’interface VF et l’interface VF a été désinscrite. À ce stade, Linux a supprimé toutes les connaissances de l’interface VF et fonctionne comme si les performances réseau accélérées n’avaient pas été activées.

[   8225.557263] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF slot 1 added
[   8225.557867] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI VMBus probing: Using version 0x10002
[   8225.566794] hv_pci e9ac9b28-cf63-4466-9ae3-4b849c3ee03b: PCI host bridge to bus cf63:00
[   8225.566797] pci_bus cf63:00: root bus resource [mem 0xfe0000000-0xfe00fffff window]
[   8225.571556] pci cf63:00:02.0: [15b3:1016] type 00 class 0x020000
[   8225.584903] pci cf63:00:02.0: reg 0x10: [mem 0xfe0000000-0xfe00fffff 64bit pref]
[   8225.662860] pci cf63:00:02.0: enabling Extended Tags
[   8225.667831] pci cf63:00:02.0: 0.000 Gb/s available PCIe bandwidth, limited by Unknown x0 link at cf63:00:02.0 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link)
[   8225.667978] pci cf63:00:02.0: BAR 0: assigned [mem 0xfe0000000-0xfe00fffff 64bit pref]

Quand l’interface VF est rajoutée une fois que la maintenance est effectuée, un nouvel appareil PCI avec le GUID spécifié est détecté. Il se voit attribuer le même ID de domaine PCI (0xcf63) que précédemment. La gestion de l'interface readd VF est identique à celle du démarrage initial.

[   8225.679672] mlx5_core cf63:00:02.0: firmware version: 14.25.8362
[   8225.888476] mlx5_core cf63:00:02.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(256) RxCqeCmprss(0)
[   8226.021016] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: VF registering: eth1
[   8226.021058] mlx5_core cf63:00:02.0 eth1: joined to eth0
[   8226.021968] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in legacy RQ
[   8226.026631] mlx5_core cf63:00:02.0 eth1: Disabling LRO, not supported in legacy RQ
[   8226.026699] mlx5_core cf63:00:02.0 enP53091s1np0: renamed from eth1
[   8226.265256] mlx5_core cf63:00:02.0 enP53091s1np0: Link up

Le pilote mlx5 initialise l’interface VF et l’interface est désormais fonctionnelle. Le résultat est similaire à celui obtenu lors du démarrage initial.

[   8226.267380] hv_netvsc 000d3af5-76bd-000d-3af5-76bd000d3af5 eth0: Data path switched to VF: enP53091s1np0

Le chemin d’accès aux données est repassé à l’interface VF.

Désactivation ou activation de la mise en réseau accélérée dans une machine virtuelle sans exécution

Vous pouvez désactiver ou activer la mise en réseau accélérée sur une carte réseau virtuelle dans une machine virtuelle sans exécution à l’aide d’Azure CLI. Par exemple :

$ az network nic update --name u1804895 --resource-group testrg --accelerated-network false

La désactivation de l'Accelerated Networking activé dans la VM invitée produit une sortie dmesg. L’action est similaire à la suppression de l’interface VF pour la maintenance de l’hôte Azure. L'activation de la mise en réseau accélérée produit le même résultat dmesg que lorsque l'interface VF est lue après l'entretien de l'hôte Azure.

Vous pouvez utiliser ces commandes d’interface de ligne de commande Azure pour simuler l'entretien d'un hôte Azure. Vous pouvez alors vérifier que vos applications ne dépendent pas à tort d'une interaction directe avec l'interface VF.

Étapes suivantes