Detalhes técnicos da Virtualização de Rede Hyper-V no Windows Server

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versões 21H2 e 20H2

A virtualização de servidores permite que várias instâncias do servidor sejam executadas simultaneamente em um único host físico, mas as instâncias do servidor são isoladas umas das outras. Cada máquina virtual opera essencialmente como se fosse o único servidor em execução no computador físico.

A virtualização de rede fornece funcionalidades semelhantes, em que várias redes virtuais (possivelmente com endereços IP sobrepostos) são executadas na mesma infraestrutura de rede física e cada rede virtual opera como se fosse a única rede virtual em execução na infraestrutura de rede compartilhada. A figure 1 exibe essa relação.

Figura 1: Virtualização do servidor x virtualização da rede

Conceitos da Virtualização de Rede Hyper-V

Na HNV (Virtualização de Rede Hyper-V), um cliente ou locatário é definido como "proprietário" de um conjunto de sub-redes IP implantadas em uma empresa ou um datacenter. Um cliente pode ser uma corporação ou uma empresa com vários departamentos ou unidades de negócios em um datacenter privado que exigem isolamento de rede, ou um locatário em um data center público hospedado por um provedor de serviços. Cada cliente pode ter uma ou mais redes virtuais no datacenter, e cada rede virtual é composta por uma ou mais sub-redes virtuais.

Há duas implementações da HNV que estarão disponíveis no Windows Server 2016: HNVv1 e HNVv2.

• HNVv1

  A HNVv1 é compatível com o Windows Server 2012 R2 e com o System Center 2012 R2 VMM (Virtual Machine Manager). A configuração da HNVv1 depende do gerenciamento do WMI e dos cmdlets do Windows PowerShell (facilitados pelo System Center VMM) para definir as configurações de isolamento, bem como os mapeamentos e o roteamento de CA (endereço do cliente) – rede virtual – para PA (endereço físico). Nenhum recurso adicional foi adicionado à HNVv1 no Windows Server 2016 e nenhum novo recurso está planejado.

  • O Agrupamento de SET e a HNV V1 não são compatíveis em termos de plataforma.

  o Para usar gateways NVGRE de HA, os usuários precisam usar a equipe LBFO ou Nenhuma equipe. Ou

  o Use gateways implantados pelo Controlador de Rede com o comutador com agrupamento SET.

• HNVv2

  Um número significativo de novos recursos está incluído na HNVv2, que é implementada usando a extensão de encaminhamento da VFP (Plataforma de Filtragem Virtual) do Azure no Comutador Hyper-V. A HNVv2 é totalmente integrada ao Microsoft Azure Stack, que inclui o novo Controlador de Rede na pilha da SDN (Rede definida por software). A política de rede virtual é definida por meio do Controlador de Rede da Microsoft usando uma API NB (NorthBound) RESTful e encaminhada a um Agente Host por meio de várias SBIs (Interfaces SouthBound), incluindo OVSDB. O Agente de Host programa a política na extensão VFP do Comutador Hyper-V em que ela é imposta.

  Importante

  Este tópico se concentra na HNVv2.

Rede virtual

• Cada rede virtual é composta por uma ou mais sub-redes virtuais. Uma rede virtual forma um limite de isolamento em que as máquinas virtuais de uma rede virtual só podem se comunicar entre si. Tradicionalmente, esse isolamento era imposto usando VLANs com um intervalo de endereços IP segregado e uma marca de 802.1q ou ID de VLAN. Com a HNV, no entanto, o isolamento é imposto usando o encapsulamento NVGRE ou VXLAN para criar redes de sobreposição com a possibilidade de sobrepor sub-redes IP entre clientes ou locatários.

• Cada rede virtual tem uma RDID (ID de domínio de roteamento) exclusiva no host. Essa RDID é mapeada aproximadamente para uma ID de Recurso para identificar o recurso REST da rede virtual no Controlador de Rede. O recurso REST da rede virtual é referenciado usando um namespace de URI (Uniform Resource Identifier) com a ID de Recurso acrescentada.

Sub-redes virtuais

• Uma sub-rede virtual implementa a semântica de sub-rede IP de Camada 3 das máquinas virtuais na mesma sub-rede virtual. A sub-rede virtual forma um domínio de transmissão (semelhante a uma VLAN) e o isolamento é imposto usando o campo de TNI (ID da rede de locatário) NVGRE ou VNI (Identificador de rede VXLAN).

• Cada sub-rede virtual pertence a somente uma RDID (rede virtual) e recebe somente uma VSID (ID de sub-rede virtual) exclusiva usando a chave TNI ou VNI no cabeçalho do pacote encapsulado. A VSID precisa ser exclusiva dentro do datacenter e estar no intervalo entre 4096 e 2^24-2.

Uma vantagem importante da rede virtual e do domínio de roteamento é permitir que os clientes tragam as próprias topologias de rede (por exemplo, sub-redes de IP) para a nuvem. A Figura 2 mostra um exemplo onde a Contoso Corp tem duas redes separadas, Rede P&D e Rede de Vendas. Como essas redes têm diferentes IDs de domínio de roteamento, elas não podem interagir entre si. Ou seja, a Rede de P e D da Contoso está isolada da Rede de Vendas da Contoso, embora ambas sejam da Contoso Corp. A Rede de P e D da Contoso contém três sub-redes virtuais. Observe que a RDID e a VSID são exclusivas dentro de um datacenter.

Figura 2: Redes de cliente e sub-redes virtuais

Encaminhamento de Camada 2

Na Figura 2, as máquinas virtuais na VSID 5001 podem ter os pacotes encaminhados para máquinas virtuais que também estão na VSID 5001 por meio do Comutador Hyper-V. Os pacotes de entrada de uma máquina virtual na VSID 5001 são enviados para uma VPort específica no Comutador Hyper-V. As regras de entrada (por exemplo, encapsulamento) e os mapeamentos (por exemplo, cabeçalho de encapsulamento) são aplicados pelo Comutador Hyper-V para esses pacotes. Em seguida, os pacotes serão encaminhados para uma VPort diferente no Comutador Hyper-V (se a máquina virtual de destino estiver anexada ao mesmo host) ou para um Comutador Hyper-V diferente em um host diferente (se a máquina virtual de destino estiver localizada em um host diferente).

Roteamento de Camada 3

De maneira semelhante, as máquinas virtuais na VSID 5001 podem ter os pacotes roteados para máquinas virtuais na VSID 5002 ou VSID 5003 pelo roteador distribuído da HNV, que está presente no VSwitch de cada host Hyper-V. Ao entregar o pacote ao comutador Hyper-V, a HNV atualiza a VSID do pacote de entrada para a VSID da máquina virtual de destino. Isso ocorrerá somente se as duas VSIDs estiverem na mesma RDID. Portanto, adaptadores de rede virtual com RDID1 não podem enviar pacotes para adaptadores de rede virtual com RDID2 sem atravessar um gateway.

Observação

Na descrição do fluxo de pacotes acima, o termo "máquina virtual" significa, na verdade, o adaptador de rede virtual na máquina virtual. O caso comum é quando uma máquina virtual tem apenas um único adaptador de rede virtual. Nesse caso, as palavras "máquina virtual" e "adaptador de rede virtual" podem significar, conceitualmente, a mesma coisa.

Cada sub-rede virtual define uma sub-rede IP de Camada 3 e um limite de domínio de difusão de Camada 2 (L2) de maneira semelhante a uma VLAN. Quando uma máquina virtual transmite um pacote, a HNV usa a UR (Replicação Unicast) para fazer uma cópia do pacote original e substituir o IP e o MAC de destino pelos endereços de cada VM que está na mesma VSID.

Observação

Quando o Windows Server 2016 é fornecido, os multicasts de transmissão e de sub-rede são implementados usando a replicação unicast. Não há suporte para roteamento multicast entre sub-redes e IGMP.

Além de ser um domínio de difusão, a VSID fornece isolamento. Um adaptador de rede virtual na HNV está conectado a uma porta de comutador Hyper-V, que terá regras de ACL aplicadas diretamente à porta (recurso REST virtualNetworkInterface) ou à sub-rede virtual (VSID) da qual faz parte.

A porta do comutador Hyper-V precisa ter uma regra de ACL aplicada. Essa ACL pode ser ALLOW ALL, DENY ALL ou pode ser mais específica para permitir somente determinados tipos de tráfego com base na correspondência de 5 tuplas (IP de origem, IP de destino, porta de origem, porta de destino, protocolo).

Observação

As Extensões de Comutador Hyper-V não funcionam com a HNVv2 na nova pilha de SDN (Rede Definida por Software). A HNVv2 é implementada usando a extensão de comutador VFP (Plataforma de Filtragem Virtual) do Azure, que não pode ser usada em conjunto com nenhuma outra extensão de comutador de terceiros.

Alternância e roteamento na Virtualização de Rede Hyper-V

A HNVv2 implementa a alternância correta da Camada 2 (L2) e a semântica de roteamento da Camada 3 (L3) para funcionar exatamente como um roteador ou comutador físico. Quando uma máquina virtual conectada a uma rede virtual HNV tenta estabelecer uma conexão com outra máquina virtual na mesma sub-rede virtual (VSID), primeiro ela precisa aprender o endereço MAC da AC da máquina virtual remota. Se houver uma entrada ARP para o endereço IP da máquina virtual de destino na tabela ARP da máquina virtual de origem, o endereço MAC dessa entrada será usado. Se não houver uma entrada, a máquina virtual de origem enviará uma transmissão ARP com uma solicitação para que o endereço MAC correspondente ao endereço IP da máquina virtual de destino seja retornado. O Comutador Hyper-V interceptará essa solicitação e a enviará para o Agente Host. O Agente Host procurará no banco de dados local um endereço MAC correspondente ao endereço IP da máquina virtual de destino solicitado.

Observação

O Agente Host, atuando como o servidor OVSDB, usa uma variante do esquema VTEP para armazenar mapeamentos de CA-PA, tabela MAC e assim por diante.

Se um endereço MAC estiver disponível, o Agente Host injetará uma resposta ARP e a enviará de volta à máquina virtual. Quando a pilha de rede da máquina virtual tiver todas as informações de cabeçalho L2 necessárias, o quadro será enviado à Porta do Hyper-V correspondente no V-Switch. Internamente, o Comutador do Hyper-V testa esse quadro em relação às regras de correspondência de N tuplas atribuídas à porta V e aplica determinadas transformações ao quadro com base nas regras. Mais importante, um conjunto de transformações de encapsulamento é aplicado para construir o cabeçalho de encapsulamento usando NVGRE ou VXLAN, dependendo da política definida no Controlador de Rede. Com base na política programada pelo Agente Host, um mapeamento de CA-PA é usado para determinar o endereço IP do host Hyper-V onde a máquina virtual de destino reside. O Comutador Hyper-V garante que as regras de roteamento e as marcas de VLAN corretas sejam aplicadas ao pacote externo para que ele atinja o endereço PA remoto.

Se uma máquina virtual conectada a uma rede virtual HNV quiser criar uma conexão com uma máquina virtual em uma VSID (sub-rede virtual) diferente, o pacote precisará ser roteado adequadamente. A HNV pressupõe uma topologia em estrela em que há apenas um endereço IP no espaço de AC usado como o próximo salto para alcançar todos os prefixos de IP (ou seja, uma rota/gateway padrão). Atualmente, isso impõe uma limitação a uma só rota padrão e não há suporte para rotas não padrão.

Roteamento Entre Sub-redes Virtuais

Em uma rede física, uma sub-rede IP é um domínio da Camada 2 (L2) em que os computadores (virtuais e físicos) podem se comunicar diretamente uns com os outros. O domínio L2 é um domínio de transmissão em que as entradas ARP (mapa de endereços IP:MAC) são aprendidas por meio de solicitações de ARP que são transmitidas em todas as interfaces e as respostas ARP são enviadas de volta ao host solicitante. O computador usa as informações de MAC aprendidas com a resposta ARP para construir completamente o quadro L2, incluindo cabeçalhos Ethernet. No entanto, se um endereço IP estiver em uma sub-rede L3 diferente, a solicitação ARP não cruzará esse limite de L3. Em vez disso, uma interface de roteador L3 (próximo salto ou gateway padrão) com um endereço IP na sub-rede de origem precisa responder a essas solicitações ARP com o próprio endereço MAC.

Na rede padrão do Windows, um administrador pode criar rotas estáticas e atribuí-las a um adaptador de rede. Além disso, um "gateway padrão" geralmente é configurado para ser o endereço IP do próximo salto em uma interface em que os pacotes destinados à rota padrão (0.0.0.0/0) são enviados. Os pacotes serão enviados a esse gateway padrão se não houver rotas específicas. Normalmente, esse é o roteador da rede física. A HNV usa um roteador interno que faz parte de cada host e tem uma interface em cada VSID para criar um roteador distribuído para as redes virtuais.

Como a HNV pressupõe uma topologia em estrela, o roteador distribuído da HNV atua como um só gateway padrão para todo o tráfego que passa pelas sub-redes virtuais que fazem parte da mesma rede VSID. O endereço usado como gateway padrão usa como padrão o endereço IP mais baixo na VSID e é atribuído ao roteador distribuído da HNV. Esse roteador distribuído proporciona uma maneira muito eficiente de rotear adequadamente todo o tráfego dentro de uma Rede VSID, uma vez que cada host pode rotear o tráfego diretamente para o host apropriado sem precisar de um intermediário. Isso é particularmente verdadeiro quando duas máquinas virtuais na mesma Rede VM, mas em diferentes Sub-redes Virtuais estão no mesmo host físico. Como você verá mais adiante nesta seção, o pacote nunca terá que sair do host físico.

Roteamento entre sub-redes PA

Ao contrário da HNVv1, que alocou um endereço IP de PA para cada VSID (sub-rede virtual), a HNVv2 agora usa um endereço IP de PA por membro da equipe de NIC do SET (Agrupamento Inserido por Comutador). A implantação padrão pressupõe uma equipe de duas NICs e atribui dois endereços IP de PA por host. Um host único tem IPs de PA atribuídos da mesma sub-rede lógica de PA (Provedor) na mesma VLAN. Duas VMs de locatário na mesma sub-rede virtual podem, de fato, estar localizadas em dois hosts diferentes conectados a duas sub-redes lógicas de provedores diferentes. A HNV construirá os cabeçalhos IP externos para o pacote encapsulado com base no mapeamento de CA-PA. No entanto, ela depende da pilha TCP/IP do host para o ARP para o gateway de PA padrão e, em seguida, cria os cabeçalhos Ethernet externos com base na resposta ARP. Normalmente, essa resposta ARP vem da interface SVI no comutador físico ou do roteador L3 em que o host está conectado. Portanto, a HNV depende do roteador L3 para rotear os pacotes encapsulados entre sub-redes lógicas/VLANs do provedor.

Roteamento Fora de uma Rede Virtual

A maioria das implantações de cliente exigirá a comunicação do ambiente de HNV com recursos que não fazem parte do ambiente de HNV. São necessários gateways de Virtualização de Rede para permitir a comunicação entre os dois ambientes. As infraestruturas que exigem um Gateway de HNV incluem a Nuvem Privada e a Nuvem Híbrida. Basicamente, gateways de HNV são necessários para o roteamento de Camada 3 entre as redes internas e externas (físicas) (incluindo a NAT) ou entre diferentes sites e/ou nuvens (privadas ou públicas) que usam um túnel GRE ou VPN IPSec.

Os gateways podem ser fornecidos em diferentes fatores forma físicos. Eles podem ser baseados no Windows Server 2016, incorporados a um comutador TOR (Top of Rack) atuando como um Gateway VXLAN, acessados por meio de um VIP (IP virtual) anunciado por um balanceador de carga, colocados em outros dispositivos de rede existentes ou podem ser um novo dispositivo de rede autônomo.

Para obter mais informações sobre as opções do Gateway RAS do Windows, consulte Gateway RAS.

Encapsulamento de Pacote

Cada adaptador de rede virtual da HNV está associado a dois endereços IP:

• Endereço do Cliente (CA) O endereço IP atribuído pelo cliente, com base na infraestrutura da intranet dele. Esse endereço permite que o cliente troque o tráfego de rede com a máquina virtual como se não tivesse migrado para uma nuvem pública ou privada. O CA é visível para a máquina virtual e está acessível para o cliente.

• Endereço do Provedor (PA) O endereço IP atribuído pelo provedor de host ou pelos administradores do datacenter com base na infraestrutura de rede física deles. O PA é exibido nos pacotes da rede que são trocados com o servidor Hyper-V que hospeda a máquina virtual. O PA está visível na rede física, mas não para a máquina virtual.

Os CAs mantêm a topologia de rede do cliente, que é virtualizada e separada dos endereços e da topologia de rede física real subjacente, conforme implementado pelos PAs. O diagrama a seguir mostra a relação conceitual entre os CAs de máquinas virtuais e os PAs da infraestrutura de rede resultantes da virtualização da rede.

Figura 6: Diagrama conceitual da virtualização de rede na infraestrutura física

No diagrama, as máquinas virtuais do cliente enviam pacotes de dados no espaço do CA, que atravessam a infraestrutura de rede física por meio das próprias redes virtuais, ou “túneis”. No exemplo acima, podemos pensar nos túneis como "envelopes" ao redor dos pacotes de dados da Contoso e da Fabrikam com etiquetas de remessa verdes (endereços PA) a serem entregues do host de origem à esquerda para o host de destino à direita. O principal é como os hosts determinam os “endereços para entrega” (PAs) correspondentes aos CAs da Contoso e da Fabrikam, como o “envelope” é colocado nos pacotes e como os hosts de destino podem desembrulhar os pacotes e entregar corretamente para as máquinas virtuais de destino da Contoso e da Fabrikam.

Essa analogia simples destacou os principais aspectos da virtualização de rede:

• Cada autoridade de certificação de máquina virtual é mapeada para um host físico PA. Pode haver diversos CAs associados ao mesmo PA.

• As máquinas virtuais enviam pacotes de dados nos espaços do CA, que são colocados em um “envelope” com um par de origem e destino de PA com base no mapeamento.

• Os mapeamentos CA-PA devem permitir que os hosts diferenciem pacotes para máquinas virtuais do cliente diferentes.

Como resultado, o mecanismo de virtualização da rede consiste em virtualizar os endereços de rede usados pelas máquinas virtuais. O controlador de rede é responsável pelo mapeamento de endereços e o agente host mantém o banco de dados de mapeamento usando o esquema MS_VTEP. A seção a seguir descreve o mecanismo real de virtualização de endereços.

Virtualização da rede por meio da virtualização de endereços

A HNV implementa redes de locatário de sobreposição usando o NVGRE (Network Virtualization Generic Routing Encapsulation) ou a VXLAN (Virtual eXtensible Local Area Network). A VXLAN é o padrão.

VXLAN (Virtual eXtensible Local Area Network)

O protocolo VXLAN (Virtual eXtensible Local Area Network; RFC 7348) foi amplamente adotado no mercado, com suporte de fornecedores como Cisco, Brocade, Arista, Dell, HP e outros. O protocolo VXLAN usa UDP como transporte. A porta de destino UDP atribuída pela IANA para VXLAN é 4789, e a porta de origem UDP deve ser um hash de informações do pacote interno a ser usado para distribuição de ECMP. Após o cabeçalho UDP, é acrescentado ao pacote um cabeçalho VXLAN que inclui um campo reservado de 4 bytes seguido por um campo de 3 bytes para o VNI (Identificador de Rede VXLAN) – VSID – seguido por outro campo reservado de 1 byte. Após o cabeçalho VXLAN, o quadro CA L2 original (sem o FCS do quadro Ethernet da AC) é acrescentado.

Encapsulamento de Roteamento Genérico (NVGRE)

Este mecanismo de virtualização de rede usa o protocolo NVGRE como parte do cabeçalho do túnel. No NVGRE, o pacote da máquina virtual é encapsulado dentro de outro pacote. O cabeçalho desse novo pacote tem os endereços IP do PA de origem e de destino, além da ID da Sub-rede Virtual, que é armazenada no campo Key do cabeçalho do GRE, como mostrado na Figura 7.

Figura 7: Virtualização de rede – encapsulamento NVGRE

A ID de Sub-rede Virtual permite que os hosts identifiquem a máquina virtual do cliente para qualquer pacote específico, embora os PAs e CAs nos pacotes possam se sobrepor. Isso permite que todas as máquinas virtuais no mesmo host compartilhem um único PA, como mostrado na Figura 7.

O compartilhamento do PA tem um grande impacto sobre a escalabilidade da rede. O número de endereços IP e MAC que devem ser aprendidos pela infraestrutura de rede pode ser reduzido significativamente. Por exemplo, se cada host final tiver uma média de 30 máquinas virtuais, o número de endereços IP e MAC que precisam ser aprendidos pela infraestrutura de rede é reduzido por um fator de 30. As IDs de Sub-rede Virtual inseridas nos pacotes também habilitam a fácil correlação de pacotes com os clientes reais.

O esquema de compartilhamento de PA para o Windows Server 2012 R2 é um PA por VSID por host. Para o Windows Server 2016, o esquema é um PA por membro da equipe de NIC.

Com o Windows Server 2016 e posterior, a HNV dá suporte total ao NVGRE e à VXLAN imediatamente; NÃO é necessário atualizar nem adquirir novo hardware de rede, como NICs (adaptadores de rede), comutadores ou roteadores. Isso ocorre porque esses pacotes conectados são pacotes IPs normais no espaço do PA, que é compatível com a infraestrutura de rede atual. No entanto, para obter o melhor desempenho, use NICs com suporte com os drivers mais recentes que dão suporte a descarregamentos de tarefas.

Exemplo de implantação multilocatário

O diagrama a seguir mostra um exemplo de implantação de dois clientes localizados em um datacenter na nuvem com a relação CA-PA definida pelas políticas de rede.

Figura 8: Exemplo de implantação multilocatário

Considere o exemplo na Figura 8. Antes de migrar para o provedor de hospedagem do serviço IaaS compartilhado:

• A Contoso Corp executava um SQL Server (chamado SQL) no endereço IP 10.1.1.11 e um servidor Web (chamado Web) no endereço IP 10.1.1.12, que usa seu SQL Server para transações de banco de dados.

• A Fabrikam Corp executava um SQL Server, também chamado SQL e atribuiu o endereço IP 10.1.1.11 e um servidor Web, também chamado Web, e também no endereço IP 10.1.1.12, que usa seu SQL Server para transações de banco de dados.

Digamos que o provedor de serviços de hospedagem tenha criado a rede lógica do provedor (PA) por meio do Controlador de Rede para corresponder à topologia de rede física. O Controlador de Rede aloca dois endereços IP de PA do prefixo IP da sub-rede lógica em que os hosts estão conectados. O controlador de rede também indica a marca VLAN apropriada para aplicar os endereços IP.

Usando o Controlador de Rede, a Contoso Corp e a Fabrikam Corp criam as respectivas redes virtuais e sub-redes com suporte da rede lógica do provedor (PA) especificada pelo provedor de serviços de hospedagem. A Contoso Corp e Fabrikam Corp migram seus respectivos SQL Servers e servidores Web para o serviço IaaS compartilhado do mesmo provedor de hospedagem onde, coincidentemente, executam as máquinas virtuais SQL no Host Hyper-V 1 e as máquinas virtuais Web (IIS7) no Host Hyper-V 2. Todas as máquinas virtuais mantêm seus endereços IP de intranet originais (seus CAs).

Ambas as empresas recebem a VSID (ID de Sub-rede Virtual) a seguir pelo Controlador de Rede, conforme indicado abaixo. O Agente Host em cada um dos hosts Hyper-V recebe os endereços IP de PA alocados do Controlador de Rede e cria duas vNICs de host PA em um compartimento de rede não padrão. Um adaptador de rede é atribuído a cada um desses vNICs de host em que o endereço IP de PA é atribuído, conforme mostrado abaixo:

• VSID e PAs das máquinas virtuais da Contoso Corp: a VSID é 5001, o PA SQL é 192.168.1.10, o PA WEB é 192.168.2.20

• VSID e PAs das máquinas virtuais da Fabrikam Corp: a VSID é 6001, o PA SQL é 192.168.1.10, o PA WEB é 192.168.2.20

O Controlador de Rede encaminha toda a política de rede (incluindo o mapeamento de CA-PA) para o Agente Host da SDN, que manterá a política em um repositório persistente (em tabelas de banco de dados OVSDB).

Quando a máquina virtual Web da Contoso Corp (10.1.1.12) no Host Hyper-V 2 cria uma conexão TCP com o SQL Server em 10.1.1.11, ocorre o seguinte:

• A VM faz uma ARPs para o endereço MAC de destino de 10.1.1.11

• A extensão VFP no vSwitch intercepta esse pacote e o envia para o Agente Host da SDN

• O Agente Host da SDN procura no repositório de políticas o endereço MAC para 10.1.1.11

• Se um MAC for encontrado, o Agente Host injetará uma resposta ARP de volta na VM

• Se um MAC não for encontrado, nenhuma resposta será enviada e a entrada ARP na VM para 10.1.1.11 será marcada como inacessível.

• A VM agora constrói um pacote TCP com os cabeçalhos Ethernet e IP de AC corretos e o envia para o vSwitch

• A extensão de encaminhamento VFP no vSwitch processa esse pacote por meio das camadas VFP (descritas abaixo) atribuídas à porta vSwitch de origem na qual o pacote foi recebido e cria uma entrada de fluxo na tabela de fluxo unificado do VFP

• O mecanismo VFP executa a correspondência de regras ou a pesquisa da tabela de fluxo para cada camada (por exemplo, a camada de rede virtual) com base nos cabeçalhos IP e Ethernet.

• A regra correspondente na camada de rede virtual faz referência a um espaço de mapeamento CA-PA e executa o encapsulamento.

• O tipo de encapsulamento (VXLAN ou NVGRE) é especificado na camada de VNet junto com a VSID.

• No caso de encapsulamento VXLAN, um cabeçalho UDP externo é construído com a VSID 5001 no cabeçalho VXLAN. Um cabeçalho IP externo é construído com o endereço PA de origem e de destino atribuídos ao Host Hyper-V 2 (192.168.2.20) e ao Host Hyper-V 1 (192.168.1.10), respectivamente, com base no repositório de políticas do Agente Host da SDN.

• Em seguida, esse pacote flui para a camada de roteamento de PA na VFP.

• A camada de roteamento de PA na VFP fará referência ao compartimento de rede usado para o tráfego de espaço de PA e uma ID de VLAN e usará a pilha TCP/IP do host para encaminhar o pacote de PA para o Host 1 do Hyper-V corretamente.

• Após o recebimento do pacote encapsulado, o Host Hyper-V 1 recebe o pacote no compartimento de rede PA e o encaminha para o vSwitch.

• A VFP processa o pacote por meio de suas camadas VFP e cria uma entrada de fluxo na tabela de fluxo unificado do VFP.

• O mecanismo VFP faz a correspondência das regras de entrada na camada de rede virtual e remove os cabeçalhos Ethernet, IP e VXLAN do pacote encapsulado externo.

• Em seguida, o mecanismo VFP encaminha o pacote para a porta vSwitch à qual a VM de destino está conectada.

Um processo semelhante para o tráfego entre as máquinas virtuais Web e SQL da Fabrikam Corp usa as configurações de política de HNV para a Fabrikam Corp. Como resultado, com a HNV, as máquinas virtuais da Fabrikam Corp e da Contoso Corp interagem como se estivessem em suas intranets originais. Elas nunca podem interagir entre si, embora estejam usando os mesmos endereços IP.

Os endereços separados (CAs e PAs), as configurações de política dos hosts Hyper-V e a conversão de endereços entre o CA e o PA para o tráfego de entrada e de saída das máquinas virtuais isolam esses conjuntos de servidores usando a Chave NVGRE ou a VNID VLXAN. Além disso, os mapeamentos de virtualização e a conversão separam a arquitetura da rede virtual da infraestrutura de rede da rede física. Embora os servidores SQL e Web da Contoso e SQL e Web da Fabrikam residam em suas próprias sub-redes IP do CA (10.1.1/24), sua implantação física ocorre em dois hosts em sub-redes PA diferentes, 192.168.1/24 e 192.168.2/24, respectivamente. A implicação é que o provisionamento de máquinas virtuais entre sub-redes e a migração ao vivo se tornam possíveis com a HNV.

Arquitetura da Virtualização de Rede Hyper-V

No Windows Server 2016, a HNVv2 é implementada usando a VFP (Virtual Filtering Platform) do Azure, que é uma extensão de filtragem NDIS no Comutador Hyper-V. O principal conceito da VFP é o de um mecanismo de fluxo de ação de correspondência com uma API interna exposta ao Agente Host da SDN para programar a política de rede. O próprio Agente Host da SDN recebe a política de rede do Controlador de Rede pelos canais de comunicação OVSDB e WCF SouthBound. Não só a política de rede virtual (por exemplo, mapeamento de CA-PA) é programada usando a VFP, mas também políticas adicionais, como ACLs, QoS e assim por diante.

A hierarquia de objetos da extensão de encaminhamento vSwitch e VFP é a seguinte:

• vSwitch

  • Gerenciamento de NIC externo

  • Descarregamentos de hardware da NIC

  • Regras de encaminhamento global

  • Porta

    • Camada de encaminhamento de saída para hairpinning

    • Listas de espaços para mapeamentos e pools de NAT

    • Tabela de fluxo unificado

    • Camada VFP

      • Tabela de fluxo

      • Grupo

      • Regra

        • As regras podem referenciar espaços

Na VFP, uma camada é criada por tipo de política (por exemplo, Rede Virtual) e é um conjunto genérico de tabelas de regra/fluxo. Ela não tem nenhuma funcionalidade intrínseca até que regras específicas sejam atribuídas a essa camada para implementar a funcionalidade. Cada camada recebe uma prioridade e as camadas são atribuídas a uma porta por prioridade crescente. As regras são organizadas em grupos com base principalmente na direção e na família de endereços IP. Os grupos também recebem uma prioridade e, no máximo, uma regra de um grupo pode corresponder a um determinado fluxo.

A lógica de encaminhamento para o vSwitch com a extensão VFP é a seguinte:

• Processamento de entrada (entrada do ponto de vista do pacote que entra em uma porta)

• Encaminhando

• Processamento de saída (saída do ponto de vista do pacote saindo de uma porta)

A VFP dá suporte ao encaminhamento MAC interno para os tipos de encapsulamento NVGRE e VXLAN, bem como ao encaminhamento externo baseado em VLAN MAC.

A extensão VFP tem um caminho lento e um caminho rápido para a passagem de pacotes. O primeiro pacote em um fluxo precisa atravessar todos os grupos de regras em cada camada e fazer uma pesquisa de regra, que é uma operação cara. No entanto, depois que um fluxo for registrado na tabela de fluxo unificado com uma lista de ações (com base nas regras correspondentes), todos os pacotes posteriores serão processados com base nas entradas da tabela de fluxo unificado.

A política de HNV é programada pelo agente host. Cada adaptador de rede de máquinas virtuais é configurado com um endereço IPv4. Esses são os CAs que serão usados pelas máquinas virtuais para se comunicarem entre si e eles são transportados nos pacotes IP das máquinas virtuais. A HNV encapsula o quadro de AC em um quadro de PA com base nas políticas de virtualização de rede armazenadas no banco de dados do agente host.

Figura 9: Arquitetura de HNV

Resumo

Os datacenters baseados em nuvem podem oferecer diversos benefícios, como escalabilidade aprimorada e melhor utilização de recursos. Para aproveitar esses possíveis benefícios, é necessária uma tecnologia que basicamente trate dos problemas de escalabilidade multilocatário em um ambiente dinâmico. A HNV foi projetada para lidar com essas questões e também para aprimorar a eficiência operacional do datacenter, separando a topologia da rede virtual para a topologia da rede física. Com base em um padrão existente, a HNV é executada no datacenter atual e opera com a infraestrutura de VXLAN existente. Agora, clientes que têm uma HNV podem consolidar seus datacenters em uma nuvem privada ou estender de maneira integrada seus datacenters para um ambiente do provedor de servidor de host com uma nuvem híbrida.

Confira também

Para saber mais sobre a HNVv2, consulte os seguintes links:

Tipo de conteúdo	Referências
Recursos da comunidade	- Blog da Arquitetura de Nuvem Privada – Perguntas: cloudnetfb@microsoft.com
RFC	- RFC de Rascunho de NVGRE - VXLAN – RFC 7348
Tecnologias relacionadas	– Para conhecer os detalhes técnicos da Virtualização de Rede Hyper-V no Windows Server 2012 R2, confira Detalhes técnicos da Virtualização de Rede Hyper-V - Controlador de Rede