Compartir por

Funcionamiento de las redes aceleradas en máquinas virtuales Linux y FreeBSD

  • Artigo

Cuando se crea una máquina virtual (VM) en Azure, se crea una interfaz de red sintética para cada NIC virtual en su configuración. La interfaz sintética es un dispositivo VMbus y usa el controlador netvsc. Los paquetes de red que usan esta interfaz sintética fluyen a través del conmutador virtual en el host de Azure y a la red física del centro de datos.

Si la máquina virtual está configurada con las redes aceleradas, se crea una segunda interfaz de red para cada NIC virtual configurada. La segunda interfaz es una función virtual (VF) de SR-IOV que ofrece la NIC de red física en el host de Azure. La interfaz VF se muestra en el invitado de Linux como un dispositivo PCI. Usa el controlador Mellanox mlx4 o mlx5 en Linux, ya que los hosts de Azure usan NIC físicas de Mellanox.

La mayoría de los paquetes de red pasan directamente entre el invitado de Linux y la NIC física sin atravesar el conmutador virtual ni ningún otro software que se ejecute en el host. Debido al acceso directo al hardware, la latencia de red es menor y se usa menos tiempo de CPU para procesar paquetes de red en comparación con la interfaz sintética.

Diferentes hosts de Azure usan diferentes modelos de NIC física de Mellanox. Linux determina automáticamente si usar el controlador mlx4 o mlx5. La infraestructura de Azure controla la ubicación de la máquina virtual en el host de Azure. Sin ninguna opción del cliente para especificar qué NIC física usa una implementación de máquina virtual, las máquinas virtuales deben incluir ambos controladores. Si una máquina virtual se detiene o desasigna y, después, se reinicia, podría volver a implementarse en el hardware con un modelo diferente de NIC física de Mellanox. Por lo tanto, podría usar el otro controlador de Mellanox.

Si la imagen de una máquina virtual no incluye un controlador para la NIC física de Mellanox, las funcionalidades de red siguen funcionando a la menor velocidad de la NIC virtual. En el portal, la CLI de Azure y Azure PowerShell, se muestra la característica de redes aceleradas como habilitada.

FreeBSD proporciona la misma compatibilidad con redes aceleradas que Linux cuando se ejecuta en Azure. En el resto de este artículo se describe Linux y se usan ejemplos de Linux, pero la misma funcionalidad está disponible en FreeBSD.

Nota

Este artículo contiene referencias al término esclavo, un término que Microsoft ya no usa. Cuando se elimine este término del software, se eliminará también de este artículo.

Vinculación

La interfaz de red sintética y la interfaz VF se emparejan automáticamente y actúan como una sola interfaz en la mayoría de los aspectos que usan las aplicaciones. El controlador netvsc realiza la unión. En función de la distribución de Linux, las reglas udev y los scripts pueden ayudar a asignar un nombre a la interfaz VF y a configurar la red.

Si la máquina virtual está configurada con varias NIC virtuales, el host de Azure proporciona un número de serie único para cada una. Permite que Linux realice el emparejamiento adecuado de interfaces sintéticas y VF para cada NIC virtual.

Las interfaces sintéticas y VF tienen la misma dirección MAC. Juntas constituyen una sola NIC desde el punto de vista de otras entidades de red que intercambian paquetes con la NIC virtual en la máquina virtual. Otras entidades no realizan ninguna acción especial debido a la existencia de la interfaz sintética y la interfaz VF.

Ambas interfaces son visibles mediante los comandos ifconfig o ip addr en Linux. Este es un ejemplo de salida 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

La interfaz sintética siempre tiene un nombre con el formato eth\<n\>. En función de la distribución de Linux, la interfaz VF puede tener un nombre con el formato eth\<n\>. O puede tener un nombre diferente en forma de enP\<n\> debido a una regla udev que cambia el nombre.

Puede determinar si una interfaz determinada es la interfaz sintética o la interfaz VF mediante la línea de comandos del shell que muestra el controlador de dispositivo que usa la interfaz:

$ ethtool -i <interface name> | grep driver

Si el controlador es hv_netvsc, es la interfaz sintética. La interfaz VF tiene un nombre de controlador que contiene "mlx". La interfaz VF también se identifica porque su campo flags incluye SLAVE. Esta marca indica que está bajo el control de la interfaz sintética que tiene la misma dirección MAC.

Las direcciones IP solo se asignan a la interfaz sintética. La salida de ifconfig o ip addr también muestra esta distinción.

Uso de la aplicación

Las aplicaciones solo deben interactuar con la interfaz sintética, como en cualquier otro entorno de red. Los paquetes de red salientes se pasan desde el controlador netvsc al controlador VF y, a continuación, se transmiten a través de la interfaz VF.

Los paquetes entrantes se reciben y procesan en la interfaz VF antes de pasar a la interfaz sintética. Las excepciones son los paquetes SYN de TCP entrantes y los paquetes de difusión o multidifusión que solo procesa la interfaz sintética.

Puede comprobar que los paquetes fluyen a través de la interfaz VF desde la salida de ethtool -S eth\<n\>. Las líneas de salida que contienen vf muestran el tráfico a través de la interfaz VF. Por ejemplo:

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 estos contadores se incrementan en la ejecución sucesiva del comando ethtool, el tráfico de red fluye a través de la interfaz VF.

Puede comprobar la existencia de la interfaz VF como un dispositivo PCI mediante el comando lspci. Por ejemplo, en la VM de generación 1, es posible que obtenga una salida similar a la siguiente. (Las máquinas virtuales de generación 2 no tienen los dispositivos PCI heredados).

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)

En este ejemplo, la última línea de salida identifica una VF de la NIC física Mellanox ConnectX-4.

El comando ethtool -l o ethtool -L (para obtener y establecer el número de colas de transmisión y recepción) es una excepción a las directrices para interactuar con la interfaz eth<n>. Puede usar este comando directamente en la interfaz VF para controlar el número de colas para la interfaz VF. El número de colas para la interfaz VF es independiente del número de colas para la interfaz sintética.

Interpretación de mensajes de inicio

Durante el arranque, Linux muestra muchos mensajes relacionados con la inicialización y configuración de la interfaz VF. También muestra información sobre la vinculación con la interfaz sintética. Comprender estos mensajes puede ser útil para identificar cualquier problema en el proceso.

Esta es una salida de ejemplo del comando dmesg, truncada para mostrar únicamente las líneas pertinentes para la interfaz VF. Dependiendo de la versión del kernel de Linux y la distribución de la máquina virtual, los mensajes pueden variar ligeramente, pero el flujo general es el mismo.

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

Se ha registrado el controlador netvsc para eth0.

[    6.944883] hv_vmbus: registering driver hv_pci

Se ha registrado el controlador PCI virtual de VMbus. Este controlador proporciona servicios PCI principales en una máquina virtual Linux en Azure. Debe registrarla antes de que se pueda detectar y configurar la interfaz VF.

[    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]

Se ha detectado el dispositivo PCI con el GUID enumerado (asignado por el host de Azure). Se le asigna un identificador de dominio PCI (0xcf63 en este caso) basado en el GUID. El identificador de dominio de PCI debe ser único en todos los dispositivos PCI disponibles en la máquina virtual. Este requisito de exclusividad abarca otras interfaces VF de Mellanox, GPU, dispositivos NVMe y otros dispositivos que pueden estar presentes en la máquina virtual.

[    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)

Se ha detectado una VF de Mellanox que usa el controlador mlx5. El controlador mlx5 comienza su inicialización del dispositivo.

[    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

La interfaz sintética correspondiente que usa el controlador netvsc ha detectado una VF coincidente. El controlador mlx5 reconoce que se ha vinculado a la interfaz sintética.

[    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

El kernel de Linux llamó inicialmente a la interfaz VF eth1. Se ha cambiado el nombre de una regla udev para evitar confusiones con los nombres asignados a las interfaces sintéticas.

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

La interfaz VF de Mellanox ahora está activa.

[    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

Estos mensajes indican que la ruta de acceso de datos para el par vinculado ha cambiado para usar la interfaz VF. Unos 1.6 segundos más tarde, vuelve a la interfaz sintética. Estas conmutaciones pueden producirse dos o tres veces durante el proceso de inicio y tienen un comportamiento normal a medida que se inicializa la configuración.

[    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

El mensaje final indica que la ruta de acceso a los datos ha cambiado para usar la interfaz VF. Se espera que esto se produzca durante el funcionamiento normal de la máquina virtual.

Mantenimiento del host de Azure

Durante el mantenimiento del host de Azure, es posible que todas las interfaces VF se quiten temporalmente de la máquina virtual durante el mantenimiento. Una vez completado el mantenimiento, las interfaces VF se agregan de nuevo a la máquina virtual. El funcionamiento sigue siendo normal. Mientras la máquina virtual funciona sin las interfaces VF, el tráfico de red sigue fluyendo a través de la interfaz sintética sin interrupciones en las aplicaciones.

En este contexto, el mantenimiento del host de Azure puede incluir la actualización de componentes de la infraestructura de red de Azure o una actualización completa del software de hipervisor del host de Azure. Estos eventos de mantenimiento se producen a intervalos de tiempo en función de las necesidades operativas de la infraestructura de Azure. Por lo general, estos eventos suceden varias veces a lo largo de un año.

El cambio automático entre la interfaz VF y la interfaz sintética garantiza que los eventos de mantenimiento no interrumpan las cargas de trabajo si las aplicaciones interactúan solo con la interfaz sintética. Las latencias y la carga de CPU pueden ser mayores durante estos períodos debido al uso de la interfaz sintética. La duración de estos períodos suele ser de aproximadamente 30 segundos, pero a veces puede durar hasta unos minutos.

La eliminación y la nueva adición de la interfaz VF durante un evento de mantenimiento es visible en la salida de dmesg de la máquina virtual. Esta es una salida típica:

[   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

La ruta de acceso a los datos se ha cambiado de la interfaz VF y se ha anulado el registro de la interfaz VF. En este momento, Linux ha eliminado toda la información sobre la interfaz VF y funciona como si las redes aceleradas no estuvieran habilitadas.

[   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]

Cuando se vuelve a agregar la interfaz VF una vez completado el mantenimiento, se detecta un nuevo dispositivo PCI con el GUID especificado. Se le asigna el mismo identificador de dominio PCI (0xcf63) que antes. El control de la interfaz VF que se vuelve a agregar es como el control durante el arranque inicial.

[   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

El controlador mlx5 inicializa la interfaz VF, y la interfaz ahora es funcional. La salida es similar a la salida obtenida durante el inicio.

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

La ruta de acceso a los datos se ha cambiado de nuevo a la interfaz VF.

Deshabilitación o habilitación de redes aceleradas en una máquina virtual sin ejecutar

Puede deshabilitar o habilitar Redes aceleradas en una NIC virtual en una máquina virtual que no se ejecuta mediante la CLI de Azure. Por ejemplo:

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

Al deshabilitar las redes aceleradas que están habilitadas en la máquina virtual invitada, se genera una salida dmesg. Es lo mismo que cuando se quita la interfaz VF para el mantenimiento del host de Azure. La habilitación de redes aceleradas genera la misma salida dmesg que cuando se vuelve a agregar la interfaz VF después del mantenimiento del host de Azure.

Puede usar estos comandos de la CLI de Azure para simular el mantenimiento del host de Azure. Después, puede comprobar que las aplicaciones no dependen incorrectamente de la interacción directa con la interfaz VF.

Pasos siguientes