Detalles técnicos de Virtualización de red de Hyper-V en Windows Server
La virtualización de servidores permite que se ejecuten varias instancias de servidor al mismo tiempo en un solo host físico; aunque las instancias del servidor estén aisladas entre sí. Cada máquina virtual básicamente funciona como si fuera el único servidor que se ejecuta en el equipo físico.
La virtualización de red ofrece una funcionalidad similar, en la que varias redes virtuales (posiblemente con direcciones IP superpuestas) se ejecutan en la misma infraestructura de red física y cada red vidual funciona como si fuese la única red virtual que se ejecuta en la infraestructura de red compartida. La Figura 1 muestra esta relación.
Figura 1: Virtualización de servidor frente a virtualización de red
Conceptos de la virtualización de red de Hyper-V
En la Virtualización de red de Hyper-V (HNV), un cliente o inquilino se define como el "propietario" de un conjunto de subredes IP que se implementan en una empresa o un centro de datos. Un cliente puede ser una corporación o empresa con varios departamentos o unidades de negocio en un centro de datos privado que requiera aislamiento de red, o bien un inquilino en un centro de datos público hospedado por un proveedor de servicios. Cada cliente puede tener una o más redes virtuales en el centro de datos, y cada red virtual se compone de una o varias subredes virtuales.
Hay dos implementaciones de HNV que estarán disponibles en Windows Server 2016: HNVv1 y HNVv2.
HNVv1
HNVv1 es compatible con Windows Server 2012 R2 y System Center 2012 R2 Virtual Machine Manager (VMM). La configuración de HNVv1 se basa en los cmdlets de administración de WMI y Windows PowerShell (facilitados a través de System Center VMM) para definir la configuración de aislamiento y la dirección del cliente (CA): red virtual, para asignaciones y enrutamiento de direcciones físicas (PA). No se han agregado características adicionales a HNVv1 en Windows Server 2016 y no se planea ninguna característica nueva.
- SET Teaming y HNV V1 no son compatibles con la plataforma.
o Para usar puertas de enlace NVGRE de alta disponibilidad, los usuarios deben usar el equipo LBFO o ningún equipo. Or
o Use puertas de enlace implementadas de la Controladora de red con el conmutador asociado SET.
HNVv2
En HNVv2 se incluye un número significativo de características nuevas que se implementan mediante la extensión de reenvío de Azure Virtual Filtering Platform (VFP) en el conmutador de Hyper-V. HNVv2 está totalmente integrado con Microsoft Azure Stack, que incluye la nueva Controladora de red en la pila de redes definidas por software (SDN). La directiva de red virtual se define mediante la Controladora de red de Microsoft con una API RESTful NorthBound (NB) y se asocia a un agente del host a través de varias interfaces de SouthBound (SBI), incluida OVSDB. La directiva de programas del agente del host en la extensión VFP del conmutador de Hyper-V donde se aplica.
Importante
Este tema se centra en HNVv2.
Virtual network
Cada red virtual consta de una o varias subredes virtuales. Una red virtual forma un límite de aislamiento donde las máquinas virtuales que están dentro de una red virtual pueden comunicarse entre sí. Tradicionalmente, este aislamiento se aplicaba mediante VLAN con un intervalo de direcciones IP segregadas y la etiqueta 802.1q o el id. de VLAN. Pero con HNV, el aislamiento se aplica mediante la encapsulación NVGRE o VXLAN para crear redes superpuestas con la posibilidad de superponer subredes IP entre clientes o inquilinos.
Cada red virtual tiene un identificador de dominio de enrutamiento único (RDID) en el host. Este RDID se asigna aproximadamente a un identificador de recurso para identificar el recurso REST de red virtual en la Controladora de red. Se hace referencia al recurso REST de red virtual mediante un espacio de nombres de identificador uniforme de recursos (URI) con el identificador de recurso anexado.
Subredes virtuales
Una subred virtual implementa la semántica de la subred IP de capa 3 para las máquinas virtuales de la misma subred virtual. La subred virtual forma un dominio de difusión (similar a una VLAN) y se aplica el aislamiento mediante el campo Identificador de red de inquilino de NVGRE (TNI) o Identificador de red VXLAN (VNI).
Cada subred virtual pertenece a una sola red virtual (RDID) y se le asigna un identificador de subred virtual (VSID) único mediante la clave TNI o VNI en el encabezado de paquete encapsulado. El VSID debe ser único en el centro de datos y se encuentra dentro del rango de 4096 a 2^24-2.
Una ventaja clave de la red virtual y del dominio de enrutamiento es que permite a los clientes llevar sus propias topologías de red (por ejemplo, subredes IP) a la nube. La Figura 2 muestra un ejemplo donde Contoso Corp cuenta con dos redes diferentes: Red de I+D y Red de ventas. Dado que estas redes cuentan con identificadores de dominio de enrutamiento diferentes, no pueden interactuar entre sí. Es decir, la Red I+D de Contoso está aislada de la Red de ventas de Contoso aunque ambas pertenezcan a Contoso Corp. La Red I+D de Contoso contiene tres subredes virtuales. Tenga en cuenta que el RDID y el VSID son únicos dentro de un centro de datos.
Figura 2: Redes del cliente y subredes virtuales
Reenvío de nivel 2
En la figura 2, las máquinas virtuales de VSID 5001 pueden reenviar sus paquetes a máquinas virtuales que también están en VSID 5001 a través del conmutador de Hyper-V. Los paquetes entrantes de una máquina virtual de VSID 5001 se envían a un VPort específico en el conmutador de Hyper-V. Las reglas de entrada (por ejemplo, la encapsulación) y las asignaciones (por ejemplo, el encabezado de encapsulación) se aplican mediante el conmutador de Hyper-V para estos paquetes. A continuación, los paquetes se reenvía a otro VPort en el conmutador de Hyper-V (si la máquina virtual de destino está conectada al mismo host) o a otro conmutador de Hyper-V en otro host (si la máquina virtual de destino se encuentra en un host diferente).
Enrutamiento de nivel 3
Del mismo modo, las máquinas virtuales de VSID 5001 pueden tener sus paquetes enrutados a máquinas virtuales en VSID 5002 o VSID 5003 por el enrutador distribuido de HNV que se encuentra en el VSwitch de cada host de Hyper-V. Una vez entregado el paquete al conmutador de Hyper-V, HNV actualiza el VSID del paquete entrante al VSID de la máquina virtual de destino. Esto solo sucederá si ambos VSID se encuentran en el mismo RDID. Por lo tanto, los adaptadores de la red virtual con RDID1 no pueden enviar paquetes a los adaptadores de la red virtual con RDID2 sin atravesar una puerta de enlace.
Nota
En la descripción anterior del flujo de paquete, el término "máquina virtual" en realidad es el adaptador de red virtual de la máquina virtual. El caso más común es que una máquina virtual contenga un solo adaptador de red virtual. En este caso, las palabras "máquina virtual" y "adaptador de red virtual" pueden significar conceptualmente lo mismo.
Cada subred virtual define una subred de IP de capa 3 y un límite de dominio de difusión (L2) de capa 2 similar a una VLAN. Cuando una máquina virtual difunde un paquete, HNV usa la replicación de unidifusión (UR) para realizar una copia del paquete original y reemplazar la dirección IP de destino y MAC por las direcciones de cada máquina virtual que se encuentran en el mismo VSID.
Nota
Cuando Windows Server 2016 se distribuye, la difusión y las multidifusiones de subred se implementarán mediante la replicación de unidifusión. El IGMP y el enrutamiento multidifusión entre subredes no se admiten.
Además de ser un dominio de difusión, el VSID proporciona aislamiento. Un adaptador de red virtual de HNV está conectado a un puerto de conmutador de Hyper-V que tendrá reglas de ACL aplicadas directamente al puerto (recurso REST virtualNetworkInterface) o a la subred virtual (VSID) de la que forma parte.
El puerto del conmutador de Hyper-V debe tener aplicada una regla de ACL. Esta ACL podría ser ALLOW ALL, DENY ALL o ser más específica para permitir solo determinados tipos de tráfico en función de la coincidencia de 5 tuplas (IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo).
Nota
Las extensiones de conmutador de Hyper-V no funcionarán con HNVv2 en la nueva pila de redes definidas por software (SDN). HNVv2 se implementa mediante la extensión del conmutador de Azure Virtual Filtering Platform (VFP), que no se puede usar junto con ninguna otra extensión de conmutador de terceros.
Conmutación y enrutamiento en Virtualización de red de Hyper-V
HNVv2 implementa la conmutación correcta de nivel 2 (L2) y la semántica de enrutamiento de nivel 3 (L3) para funcionar exactamente igual a como funcionaría un conmutador físico o un enrutador. Cuando una máquina virtual conectada a una red virtual HNV intenta establecer una conexión con otra máquina virtual en la misma subred virtual (VSID), primero tendrá que aprender la dirección MAC de la CA de la máquina virtual remota. Si hay una entrada ARP para la dirección IP de la máquina virtual de destino en la tabla ARP de la máquina virtual de origen, se usa la dirección MAC de esta entrada. Si no existe ninguna entrada, la máquina virtual de origen enviará una difusión ARP con una solicitud de la dirección MAC correspondiente a la dirección IP de la máquina virtual de destino que se devolverá. El conmutador de Hyper-V interceptará esta solicitud y la enviará al agente del host. El agente del host buscará en su base de datos local una dirección MAC correspondiente para la dirección IP de la máquina virtual de destino solicitada.
Nota
El agente del host, que actúa como servidor OVSDB, usa una variante del esquema VTEP para almacenar asignaciones de CA-PA, tabla MAC, etc.
Si hay disponible una dirección MAC, el agente del host inserta una respuesta ARP y la devuelve a la máquina virtual. Después de que la pila de redes de la máquina virtual tenga toda la información de encabezado L2 necesaria, el marco se envía al puerto de Hyper-V correspondiente de V-Switch. Internamente, el conmutador de Hyper-V prueba este marco con las reglas de coincidencia de tupla N asignadas al puerto V y aplica determinadas transformaciones al marco en función de estas reglas. Lo más importante es que se aplica un conjunto de transformaciones de encapsulación para construir el encabezado de encapsulación mediante NVGRE o VXLAN, en función de la directiva definida en la Controladora de red. En función de la directiva programada por el agente del host, se usa una asignación de CA-PA para determinar la dirección IP del host de Hyper-V donde reside la máquina virtual de destino. El conmutador de Hyper-V garantiza que las reglas de enrutamiento y las etiquetas VLAN correctas se apliquen al paquete externo para que acceda a la dirección PA remota.
Si una máquina virtual conectada a una red virtual de HNV quiere crear una conexión con una máquina virtual en otra subred virtual (VSID), el paquete debe enrutarse en consecuencia. HNV asume la existencia de una topología de estrella en la que solo hay una dirección IP en el espacio de CA que se usa como próximo salto para acceder a todos los prefijos IP (que significa una ruta o puerta de enlace predeterminada). Actualmente, esto aplica una limitación a una única ruta predeterminada, y no se admiten rutas no predeterminadas.
Enrutamiento entre subredes virtuales
En una red física, una subred IP es un dominio de nivel 2 (L2) en el que los equipos (virtuales y físicos) pueden comunicarse directamente entre sí. El dominio L2 es un dominio de difusión donde las entradas de ARP (mapa de direcciones IP:MAC) se aprenden mediante solicitudes de ARP que se difunden en todas las interfaces, y las respuestas de ARP se devuelven al host solicitante. El equipo usa la información MAC aprendida de la respuesta de ARP para construir completamente el marco L2, incluidos los encabezados Ethernet. Sin embargo, si una dirección IP está en una subred L3 diferente, la solicitud de ARP no cruza este límite L3. En su lugar, una interfaz de enrutador L3 (próximo salto o puerta de enlace predeterminada) con una dirección IP en la subred de origen debe responder a estas solicitudes de ARP con su propia dirección MAC.
En las redes estándar de Windows, un administrador puede crear rutas estáticas y asignarlas a una interfaz de red. Además, normalmente se configura una "puerta de enlace predeterminada" para que sea la dirección IP del próximo salto en una interfaz donde se envían paquetes destinados a la ruta predeterminada (0.0.0.0/0). Los paquetes se envían a esta puerta de enlace predeterminada si no existen rutas específicas. Normalmente se trata del enrutador de la red física. HNV usa un enrutador integrado que forma parte de cada host y tiene una interfaz en cada VSID para crear un enrutador distribuido para las redes virtuales.
Dado que HNV asume la existencia de una topología de estrella, el enrutador distribuido de HNV actúa como una única puerta de enlace predeterminada para todo el tráfico que fluye entre subredes virtuales que forman parte de la misma red VSID. La dirección usada como puerta de enlace predeterminada tiene como valor predeterminado la dirección IP más baja del VSID y se asigna al enrutador distribuido de HNV. Este enrutador distribuido facilita una manera eficaz de que todo el tráfico que circula dentro de una red VSID se enrute adecuadamente, ya que cada host puede enrutar directamente el tráfico al host correspondiente sin necesidad de intermediarios. Esto es especialmente cierto cuando dos máquinas virtuales que se encuentran en la misma subred de VM, pero en diferentes subredes virtuales, están en el mismo host físico. Como verá más adelante en esta sección, el paquete nunca debe abandonar el host físico.
Enrutamiento entre subredes de PA
A diferencia de HNVv1, que asignó una dirección IP de PA para cada subred virtual (VSID), HNVv2 ahora usa una dirección IP de PA por cada miembro del equipo NIC de Switch-Embedded Teaming (SET). La implementación predeterminada asume la existencia de un equipo de dos NIC y asigna dos direcciones IP de PA por host. Un único host tiene direcciones IP de PA asignadas desde la misma subred lógica del proveedor (PA) en la misma VLAN. Dos máquinas virtuales de inquilino en la misma subred virtual pueden encontrarse en dos hosts diferentes que están conectados a dos subredes lógicas de proveedor distintas. HNV construirá los encabezados IP externos para el paquete encapsulado en función de la asignación de CA-PA. Sin embargo, se basa en la pila TCP/IP del host en ARP para la puerta de enlace de PA predeterminada y, a continuación, compila los encabezados Ethernet externos basados en la respuesta de ARP. Normalmente, esta respuesta de ARP procede de la interfaz SVI del conmutador físico o del enrutador L3 donde está conectado el host. Por lo tanto, HNV se basa en el enrutador L3 para enrutar los paquetes encapsulados entre subredes lógicas o VLAN del proveedor.
Enrutamiento fuera de una red virtual
La mayoría de las implementaciones de clientes requerirán comunicación desde el entorno de HNV a los recursos que no forman parte de dicho entorno. Se requieren puertas de enlace de Virtualización de red para permitir la comunicación entre los dos entornos. Las infraestructuras que requieren una puerta de enlace de HNV incluyen la nube privada y la nube híbrida. Básicamente, las puertas de enlace de HNV son necesarias para el enrutamiento de nivel 3 entre redes internas y externas (físicas) (incluida NAT) o entre diferentes sitios o nubes (privadas o públicas) que usan un túnel VPN o GRE de IPSec.
Las puertas de enlace pueden venir en diferentes factores de forma físicos. Se pueden compilar en Windows Server 2016, incorporarse en un conmutador Top of Rack (TOR) que actúa como una puerta de enlace VXLAN, a la que se accede a través de una dirección IP virtual (VIP) anunciada por un equilibrador de carga, colocarse en otros dispositivos de red existentes o puede ser un nuevo dispositivo de red independiente.
Para obtener más información sobre las opciones de puerta de enlace RAS de Windows, consulte Puerta de enlace RAS.
Encapsulación de paquetes
Cada adaptador de red virtual en HNV está asociado a dos direcciones IP:
Dirección del cliente (CA): la dirección IP que asigna el cliente en base a su infraestructura de intranet. Esta dirección permite al cliente intercambiar tráfico de red con la máquina virtual como si no se hubiese movido a una nube pública o privada. La CA está visible para la máquina virtual y el cliente puede obtener acceso a ella.
Dirección de proveedor (PA): la dirección IP asignada por el proveedor de servicios de hosting o los administradores de centros de datos en base a su infraestructura de red física. La PA aparece en los paquetes de la red que se intercambian con el servidor que ejecuta Hyper-V que hospeda la máquina virtual. La PA está visible en la red física, pero no lo está para la máquina virtual.
Las CA mantienen la topología de red del cliente, que está virtualizada y desacoplada de la topología y las direcciones de red física subyacente real, tal como lo implementan las PA. En el siguiente diagrama se muestra la relación conceptual entre las CA de máquinas virtuales y las PA de infraestructura de red como resultado de la virtualización de red.
Figura 6: Diagrama conceptual de virtualización de red a través de una infraestructura física
En el diagrama, las máquinas virtuales del cliente envían paquetes de datos en el espacio de CA, que atraviesan la infraestructura de red física a través de sus propias redes virtuales o "túneles". En el ejemplo anterior, los túneles pueden considerarse como "sobres" alrededor de los paquetes de datos de Contoso y Fabrikam con etiquetas verdes de envío (direcciones PA) que se entregan desde el host de origen de la izquierda al host de destino de la derecha. La clave es la forma en que los hosts determinan las "direcciones de envío" (PA) que corresponden a las CA de Contoso y Fabrikam, la forma en que se coloca el "sobre" alrededor de los paquetes y la forma en que los hosts de destino pueden desenvolver los paquetes y entregarlos correctamente a las máquinas virtuales de destino de Contoso y Fabrikam.
Esta simple comparación destacó los aspectos clave de la virtualización de red:
La CA de cada máquina virtual se asigna a una PA de host físico. Puede haber varios CA asociados a la misma PA.
Las máquinas virtuales envían paquetes de datos en los espacios de CA, que se colocan en un "sobre" con un par de origen y destino de PA en base a la asignación.
Las asignaciones de CA-PA deben permitir a los hosts diferenciar paquetes de diferentes equipos virtuales del cliente.
Como resultado, el mecanismo para virtualizar la red es virtualizar las direcciones de red que utilizan las máquinas virtuales. La Controladora de red es responsable de la asignación de direcciones, y el agente del host mantiene la base de datos de asignación mediante el esquema MS_VTEP. En la próxima sección se describe el mecanismo real de virtualización de direcciones.
Virtualización de red a través de virtualización de direcciones
HNV implementa redes de inquilinos de superposición mediante Network Virtualization Generic Routing Encapsulation (NVGRE) o Virtual Extensible Local Area Network (VXLAN). VXLAN es el valor predeterminado.
Virtual eXtensible Local Area Network (VXLAN)
El protocolo Virtual eXtensible Local Area Network (VXLAN) (RFC 7348) ha sido ampliamente adoptado en el mercado, con soporte de proveedores como Cisco, Brocade, Arista, Dell o HP, entre otros. El protocolo VXLAN usa UDP como transporte. El puerto de destino UDP asignado por IANA para VXLAN es 4789 y el puerto de origen UDP debe ser un hash de información del paquete interno que se usará para la propagación de ECMP. Después del encabezado UDP, se anexa un encabezado VXLAN al paquete que incluye un campo reservado de 4 bytes seguido de un campo de 3 bytes para el identificador de red VXLAN (VNI), VSID, seguido de otro campo reservado de 1 byte. Después del encabezado VXLAN, se anexa el marco L2 de CA original (sin el FCS del marco Ethernet de la CA).
Generic Routing Encapsulation (NVGRE)
Este mecanismo de virtualización de red usa Generic Routing Encapsulation (NVGRE) como parte del encabezado de túnel. En NVGRE, el paquete de la máquina virtual está encapsulado dentro de otro paquete. El encabezado de este nuevo paquete tiene las direcciones IP PA de origen y de destino apropiadas, además del identificador de subred virtual, que se almacena en el campo Clave del encabezado GRE, como se muestra en la Figura 7.
Figura 7: Virtualización de red - Encapsulación NVGRE
El identificador de subred virtual permite a los hosts identificar la máquina virtual del cliente para cualquier paquete dado, aunque las PA y las CA de los paquetes puedan superponerse. Esto permite a las máquinas virtuales del mismo host compartir una sola PA, como se muestra en la Figura 7.
Compartir la PA tiene un gran impacto en la escalabilidad de la red. La cantidad de direcciones IP y MAC que la infraestructura de red necesita detectar puede reducirse sustancialmente. Por ejemplo, si cada host extremo tiene un promedio de 30 máquinas virtuales, la cantidad de direcciones IP y MAC que debe detectar la infraestructura de red se reduce en un factor de 30. Los identificadores de subred virtual insertados en los paquetes también permiten la fácil correlación de paquetes con los clientes reales.
El esquema de uso compartido de PA para Windows Server 2012 R2 es un PA por VSID por host. Para Windows Server 2016, el esquema es un PA por miembro del equipo NIC.
Con Windows Server 2016 y versiones posteriores, HNV es totalmente compatible con NVGRE y VXLAN tal y como se entrega; NO requiere la actualización ni la compra de nuevo hardware de red como NIC (adaptadores de red), conmutadores o enrutadores. Esto se debe a que estos paquetes de la red son paquetes IP comunes en el espacio de PA, compatibles con la infraestructura de red de hoy. Sin embargo, para obtener el mejor rendimiento, use las NIC compatibles con los controladores más recientes que admiten descargas de tareas.
Ejemplo de implementación multiinquilino
El siguiente gráfico muestra un ejemplo de implementación de dos clientes que se encuentran en un centro de datos de nube con la relación entre CA y PA que definen las directivas de red.
Figura 8: Ejemplo de implementación multiempresa
Considere el ejemplo en la Figura 8. Antes de pasar al servicio IaaS compartido del proveedor de hospedaje:
Contoso Corp ejecutó un servidor SQL Server (llamado SQL) en la dirección IP 10.1.1.11 y un servidor web (llamado Web) en la dirección IP 10.1.1.12, que usa SQL Server para transacciones de bases de datos.
Fabrikam Corp ejecutó un servidor SQL Server, también llamado SQL y asignó la dirección IP 10.1.1.11 y un servidor web, también llamado Web y también la dirección IP 10.1.1.12 que usa SQL Server para transacciones de bases de datos.
Se supone que el proveedor de servicios de hospedaje ha creado previamente la red lógica del proveedor (PA) a través de la Controladora de red para que se corresponda con su topología de red física. La Controladora de red asigna dos direcciones IP de PA desde el prefijo IP de la subred lógica donde están conectados los hosts. La Controladora de red también indica la etiqueta VLAN adecuada para aplicar las direcciones IP.
Con la Controladora de red, Contoso Corp y Fabrikam Corp crean su red virtual y subredes respaldadas por la red lógica del proveedor (PA) especificada por el proveedor de servicios de hospedaje. Contoso Corp y Fabrikam Corp mueven sus respectivos servidores SQL Server y sus servidores web al mismo servicio IaaS compartido del proveedor de hospedaje donde, casualmente, ejecutan las máquinas virtuales SQL en el host 1 de Hyper-V y las máquinas virtuales (IIS7) Web en el host 2 de Hyper-V. Todas las máquinas virtuales conservan las direcciones IP de intranet originales (sus CA).
La Controladora de red asigna a ambas empresas el siguiente identificador de subred virtual (VSID), como se indica a continuación. El agente del host de cada uno de los hosts de Hyper-V recibe las direcciones IP de PA asignadas de la Controladora de red y crea dos vNIC de host PA en un compartimiento de red no predeterminado. Se asigna una interfaz de red a cada una de estas vNIC de host donde se asigna la dirección IP de PA, como se muestra a continuación:
VSID y PA de máquinas virtuales de Contoso Corp: VSID es 5001, PA de SQL es 192.168.1.10 y PA web es 192.168.2.20
VSID y PA de máquinas virtuales de Fabrikam Corp: VSID es 6001, PA de SQL es 192.168.1.10 y PA web es 192.168.2.20
La Controladora de red asocia todas las directivas de red (incluida la asignación de CA-PA) al agente del host de SDN, que mantendrá la directiva en un almacén persistente (en tablas de base de datos de OVSDB).
Cuando la máquina virtual web de Contoso Corp (10.1.1.12) del host 2 de Hyper-V crea una conexión TCP a SQL Server en 10.1.1.11, sucede lo siguiente:
ARP de máquina virtual para la dirección MAC de destino de 10.1.1.11
La extensión VFP del vSwitch intercepta este paquete y lo envía al agente del host de SDN.
El agente del host de SDN busca en su almacén de directivas la dirección MAC para 10.1.1.11.
Si se encuentra una dirección MAC, el agente del host inserta una respuesta de ARP en la máquina virtual.
Si no se encuentra una dirección MAC, no se envía ninguna respuesta, y la entrada de ARP de la máquina virtual para 10.1.1.11 está marcada como inaccesible.
La máquina virtual ahora construye un paquete TCP con los encabezados Ethernet e IP de CA correctos y los envía al vSwitch.
La extensión de reenvío de VFP de vSwitch procesa este paquete a través de las capas de VFP (descritas a continuación) asignadas al puerto vSwitch de origen en el que se recibió el paquete y crea una nueva entrada de flujo en la tabla de flujo unificado de VFP.
El motor VFP realiza una coincidencia de reglas o una búsqueda de tabla de flujo para cada capa (por ejemplo, capa de red virtual) basada en los encabezados IP y Ethernet.
La regla coincidente de la capa de red virtual hace referencia a un espacio de asignación de CA-PA y realiza la encapsulación.
El tipo de encapsulación (VXLAN o NVGRE) se especifica en la capa de VNet junto con el VSID.
En el caso de la encapsulación de VXLAN, se construye un encabezado UDP externo con el VSID de 5001 en el encabezado VXLAN. Un encabezado IP externo se construye con la dirección PA de origen y destino asignada al host 2 de Hyper-V (192.168.2.20) y el host 1 de Hyper-V (192.168.1.10) respectivamente en función del almacén de directivas del agente del host de SDN.
A continuación, este paquete fluye a la capa de enrutamiento de PA en VFP.
La capa de enrutamiento de PA en VFP hará referencia al compartimiento de red usado para el tráfico del espacio PA y un identificador de VLAN y usará la pila TCP/IP del host para reenviar el paquete de PA al host 1 de Hyper-V correctamente.
Tras recibir el paquete encapsulado, el host 1 de Hyper-V recibe el paquete en el compartimiento de red de PA y lo reenvía al vSwitch.
VFP procesa el paquete a través de sus capas de VFP y crea una entrada de flujo en la tabla de flujo unificado de VFP.
El motor VFP coincide con las reglas de entrada de la capa de red virtual y quita los encabezados Ethernet, IP y VXLAN del paquete encapsulado externo.
A continuación, el motor VFP reenvía el paquete al puerto vSwitch al que está conectada la máquina virtual de destino.
Un proceso similar para el tráfico entre las máquinas virtuales de Fabrikam Corp Web y SQL usa la configuración de la directiva de HNV de Fabrikam Corp. Como resultado, con HNV, las máquinas virtuales de Fabrikam Corp y Contoso Corp interactúan como si estuviesen en las intranet originales. Nunca pueden interactuar entre sí aunque usen las mismas direcciones IP.
Las direcciones separadas (CA y PA), la configuración de la directiva de los hosts de Hyper-V y la traducción de direcciones entre la CA y la PA para el tráfico entrante y saliente de las máquinas virtuales aíslan estos conjuntos de servidores mediante la clave de NVGRE o el VNID de VLXAN. Además, las asignaciones de virtualización y la transformación desacoplan la arquitectura de la red virtual de la infraestructura de la red física. Si bien Contoso SQL y Web y Fabrikam SQL y Web residen en sus propias subredes IP CA (10.1.1/24), las implementaciones físicas se producen en dos hosts de diferentes subredes PA, 192.168.1/24 y 192.168.2/24, respectivamente. La implicación es que el aprovisionamiento de máquinas virtuales entre subredes y la migración en vivo son posibles con HNV.
Arquitectura de Virtualización de red de Hyper-V
En Windows Server 2016, HNVv2 se implementa mediante Azure Virtual Filtering Platform (VFP), que es una extensión de filtrado NDIS dentro del conmutador de Hyper-V. El concepto clave de VFP es el de un motor de flujo de Coincidencia-Acción con una API interna expuesta al agente del host de SDN para programar la directiva de red. El propio agente del host de SDN recibe la directiva de red de la Controladora de red a través de los canales de comunicación OVSDB y WCF SouthBound. La directiva de red virtual (por ejemplo, la asignación de CA-PA) no solo se programa mediante VFP, sino también con una directiva adicional, como ACL, QoS, etc.
La jerarquía de objetos de la extensión de reenvío de vSwitch y VFP es la siguiente:
vSwitch
Administración de NIC externa
Descargas de hardware NIC
Reglas de reenvío global
Port
Capa de reenvío de salida para la conexión
Listas de espacios para asignaciones y grupos NAT
Tabla de flujo unificado
Capa VFP
Tabla de flujos
Grupo
Regla
- Las reglas pueden hacer referencia a espacios
En el VFP, se crea una capa por tipo de directiva (por ejemplo, Virtual Network) y es un conjunto genérico de tablas de reglas o flujos. No tiene ninguna funcionalidad intrínseca hasta que se asignen reglas específicas a esa capa para implementar dicha funcionalidad. A cada capa se le asigna una prioridad, y las capas se asignan a un puerto por prioridad ascendente. Las reglas se organizan en grupos basados principalmente en la dirección y la familia de direcciones IP. A los grupos también se les asigna una prioridad y, como máximo, una regla de un grupo puede coincidir con un flujo determinado.
La lógica de reenvío para vSwitch con la extensión VFP es la siguiente:
Procesamiento de entrada (entrada desde el punto de vista del paquete que entra en un puerto)
Reenvío
Procesamiento de salida (salida desde el punto de vista del paquete que sale de un puerto)
VFP admite el reenvío MAC interno para los tipos de encapsulación NVGRE y VXLAN, así como el reenvío externo basado en VLAN mediante MAC.
La extensión VFP tiene una ruta de acceso lenta y una ruta de acceso rápida para el recorrido de paquetes. El primer paquete de un flujo debe recorrer todos los grupos de reglas de cada capa y realizar una búsqueda de reglas que sea una operación costosa. Sin embargo, una vez registrado un flujo en la tabla de flujo unificado con una lista de acciones (basadas en las reglas coincidentes), todos los paquetes posteriores se procesarán en función de las entradas de la tabla de flujo unificado.
El agente del host programa la directiva de HNV. Cada adaptador de red de máquina virtual se configura con una dirección IPv4. Estas son las CA que utilizarán las máquinas virtuales para comunicarse entre sí y se pueden transportar en los paquetes IP desde las máquinas virtuales. HNV encapsula el marco de CA en un marco de PA en función de las directivas de virtualización de red almacenadas en la base de datos del agente del host.
Figura 9: Arquitectura de HNV
Resumen
Los centros de datos basados en la nube pueden proporcionar muchos beneficios como mayor escalabilidad y mejor utilización de los recursos. Advertir estos beneficios potenciales requiere una tecnología que fundamentalmente aborde los problemas de escalabilidad multiempresa en un entorno dinámico. HNV se diseñó para abordar estos problemas y también mejorar la eficacia operativa del centro de datos al desacoplar la topología de red virtual para la topología de red física. Basándose en un estándar existente, HNV se ejecuta en el centro de datos actual y funciona con la infraestructura VXLAN existente. Con HNV, ahora los clientes pueden consolidar sus centros de datos en una nube privada o ampliar sin problemas sus centros de datos a un entorno del proveedor de servidores de hospedaje con una nube híbrida.
Vea también
Para obtener más información sobre HNVv2, vea los siguientes vínculos:
| Tipo de contenido | Referencias |
|---|---|
| Recursos de comunidad | - Blog de arquitectura de nubes privadas - Formule preguntas: cloudnetfb@microsoft.com |
| RFC | - RFC borrador de NVGRE - VXLAN - RFC 7348 |
| Tecnologías relacionadas | - Para obtener detalles técnicos sobre la Virtualización de red de Hyper-V en Windows Server 2012 R2, consulte Detalles técnicos de la Virtualización de red de Hyper-V. - Controladora de red |