Hyper-V Detalhes técnicos da virtualização de rede no Windows Server

A virtualização de servidores permite que várias instâncias de servidor sejam executadas simultaneamente em um único host físico; no entanto, 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 um recurso semelhante, no qual várias redes virtuais (potencialmente 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 Figura 1 mostra essa relação.

Figura 1: Virtualização de servidores versus virtualização de rede

Hyper-V Conceitos de virtualização de rede

No Hyper-V Network Virtualization (HNV), um cliente ou locatário é definido como o "proprietário" de um conjunto de sub-redes IP implantadas em uma empresa ou datacenter. Um cliente pode ser uma corporação ou 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 consiste em uma ou mais sub-redes virtuais.

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

• HNVv1

  O HNVv1 é compatível com o Windows Server 2012 R2 e o System Center 2012 R2 Virtual Machine Manager (VMM). A configuração do HNVv1 depende do gerenciamento 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 dos Endereços do Cliente (CA) para Endereços Físicos (PA) - dentro da rede virtual. Nenhum recurso adicional foi adicionado ao HNVv1 no Windows Server 2016 e nenhum novo recurso está planejado.

  • SET Teaming e HNV V1 não são compatíveis por plataforma.

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

  o Usar gateways implantados pelo controlador de rede com switch agrupado SET.

• HNVv2

  Um número significativo de novos recursos está incluído no HNVv2, que é implementado usando a extensão de encaminhamento da Plataforma de Filtragem Virtual (VFP) do Azure no Comutador Hyper-V. O HNVv2 é totalmente integrado com o Microsoft Azure Stack, que inclui o novo Controlador de Rede na Pilha de Redes Definidas por Software (SDN). A política de rede virtual é definida através do Microsoft Network Controller usando uma API RESTful NorthBound (NB) e aplicada a um Agente Host por diversas interfaces SouthBound (SBI), incluindo OVSDB. O Host Agent programa a política na extensão VFP do interruptor Hyper-V, onde é implementada.

  Importante

  Este tópico se concentra em HNVv2.

Rede virtual

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

• Cada rede virtual tem um ID de Domínio de Roteamento (RDID) exclusivo no host. Este RDID corresponde aproximadamente a um 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 URI (Uniform Resource Identifier) com a ID de recurso anexada.

Sub-redes virtuais

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

• Cada sub-rede virtual pertence a uma única rede virtual (RDID) e é atribuída uma ID de sub-rede virtual (VSID) exclusiva usando a chave TNI ou VNI no cabeçalho do pacote encapsulado. O VSID deve ser exclusivo dentro do datacenter e está no intervalo de 4096 a 2^24-2.

Uma das principais vantagens da rede virtual e do domínio de roteamento é que ele permite que os clientes tragam suas próprias topologias de rede (por exemplo, sub-redes IP) para a nuvem. A Figura 2 mostra um exemplo em que a Contoso Corp tem duas redes separadas, a R&D Net e a Sales Net. Como essas redes têm IDs de domínio de roteamento diferentes, elas não podem interagir entre si. Ou seja, a Contoso R&D Net está isolada da Contoso Sales Net mesmo que ambas sejam de propriedade da Contoso Corp. A Contoso R&D Net contém três sub-redes virtuais. Observe que o RDID e o VSID são exclusivos dentro de um datacenter.

Figura 2: Redes de clientes e sub-redes virtuais

Encaminhamento de camada 2

Na Figura 2, as máquinas virtuais no VSID 5001 podem ter seus pacotes encaminhados para máquinas virtuais que também estão no VSID 5001 por meio do Comutador Hyper-V. Os pacotes de entrada de uma máquina virtual no VSID 5001 são enviados para um VPort específico no Hyper-V Switch. Regras de entrada (por exemplo, encap) e mapeamentos (por exemplo, cabeçalho de encapsulamento) são aplicados pelo Hyper-V Switch para esses pacotes. Os pacotes são então encaminhados para um VPort diferente no Comutador Hyper-V (se a máquina virtual de destino estiver conectada ao mesmo host) ou para um comutador de Hyper-V diferente em um host diferente (se a máquina virtual de destino estiver localizada em um host diferente).

Roteamento de camada 3

Da mesma forma, as máquinas virtuais no VSID 5001 podem ter seus pacotes roteados para máquinas virtuais no VSID 5002 ou VSID 5003 pelo roteador distribuído HNV que está presente no VSwitch de cada host Hyper-V. Ao entregar o pacote para o switch Hyper-V, a HNV atualiza o VSID do pacote de entrada para o VSID da máquina virtual de destino. Isso só acontecerá se ambos os VSIDs estiverem no mesmo 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" na verdade significa o adaptador de rede virtual na máquina virtual. O caso comum é que uma máquina virtual tem apenas um único adaptador de rede virtual. Neste caso, as palavras "máquina virtual" e "adaptador de rede virtual" podem conceitualmente significar 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) semelhante a uma VLAN. Quando uma máquina virtual transmite um pacote, a HNV usa a Replicação Unicast (UR) 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ão no mesmo VSID.

Observação

Quando o Windows Server 2016 for lançado, as multicasts de broadcast e de sub-rede serão implementadas 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 transmissão, o VSID fornece isolamento. Um adaptador de rede virtual no HNV está ligado a uma porta de switch Hyper-V, a qual terá regras de ACL aplicadas diretamente na porta (recurso REST do virtualNetworkInterface) ou na sub-rede virtual (VSID) da qual faz parte.

A porta do switch Hyper-V deve ter uma regra ACL aplicada. Esta ACL pode ser PERMITIR TUDO, BLOQUEAR TUDO, ou ser mais específica para permitir apenas certos tipos de tráfego com base na correspondência de um conjunto de 5 campos (IP de origem, IP de destino, porta de origem, porta de destino, protocolo).

Observação

Hyper-V Extensões do Switch não funcionarão com HNVv2 na nova stack de rede definida por software (SDN). O HNVv2 é implementado usando a extensão de switch VFP (Plataforma de Filtragem Virtual do Azure), que não pode ser usada em conjunto com qualquer outra extensão de switch de 3ª parte.

Comutação e roteamento na virtualização de rede Hyper-V

O HNVv2 implementa a semântica correta de comutação de Camada 2 (L2) e roteamento de Camada 3 (L3) para funcionar exatamente como um switch físico ou roteador funcionaria. 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), ela primeiro precisará aprender o endereço MAC da CA 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 uma entrada não existir, 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 Hyper-V Switch intercetará essa solicitação e a enviará para o Host Agent. O Host Agent procurará em seu banco de dados local um endereço MAC correspondente para o endereço IP da máquina virtual de destino solicitada.

Observação

O Host Agent, agindo 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 Host Agent injetará uma resposta ARP e a enviará de volta para a máquina virtual. Depois que a pilha de rede da máquina virtual tiver todas as informações de cabeçalho L2 necessárias, o quadro será enviado para a porta Hyper-V correspondente no V-Switch. Internamente, o Hyper-V Switch testa esta estrutura em relação às regras de correspondência de N-tuplas atribuídas à V-Port e aplica determinadas transformações à estrutura com base nessas regras. Mais importante ainda, 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 Host Agent, um mapeamento de CA-PA é usado para determinar o endereço IP do host de Hyper-V onde reside a máquina virtual de destino. O Hyper-V Switch garante que as regras de roteamento corretas e as tags VLAN 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 sub-rede virtual diferente (VSID), o pacote precisará ser roteado adequadamente. A HNV assume uma topologia em estrela onde há apenas um endereço IP no espaço da autoridade de certificação usado como o próximo salto para alcançar todos os prefixos IP (ou seja, uma rota/gateway padrão). Atualmente, isso impõe uma limitação a uma única rota padrão e rotas não padrão não são suportadas.

Roteamento entre sub-redes virtuais

Em uma rede física, uma sub-rede IP é um domínio de Camada 2 (L2) onde os computadores (virtuais e físicos) podem se comunicar diretamente entre si. O domínio L2 é um domínio de difusão onde as entradas ARP (mapa de endereços IP:MAC) são aprendidas através de solicitações ARP que são transmitidas em todas as interfaces e as respostas ARP são enviadas de volta para o host solicitante. O computador usa as informações 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 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 deve responder a essas solicitações ARP com seu próprio endereço MAC.

Na rede padrão do Windows, um administrador pode criar rotas estáticas e atribuí-las a uma interface de rede. Além disso, um "gateway padrão" geralmente é configurado como o endereço IP do próximo salto numa interface onde os pacotes destinados à rota de destino padrão (0.0.0.0/0) são enviados. Os pacotes são enviados para esse gateway padrão se não existirem rotas específicas. Este é normalmente o router para a sua 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 a(s) rede(s) virtual(is).

Como a HNV assume uma topologia em estrela, o router distribuído da HNV atua como um único gateway de rede predefinido para todo o tráfego entre Sub-redes Virtuais que fazem parte da mesma rede VSID. O endereço usado como gateway padrão assume como padrão o endereço IP mais baixo no VSID e é atribuído ao roteador distribuído HNV. Este roteador distribuído permite uma maneira muito eficiente para que todo o tráfego dentro de uma rede VSID seja roteado adequadamente, porque cada host pode rotear diretamente o tráfego para o host apropriado sem precisar de um intermediário. Isso é particularmente verdadeiro quando duas máquinas virtuais na mesma rede VM, mas sub-redes virtuais diferentes, estão no mesmo host físico. Como você verá mais adiante nesta seção, o pacote nunca precisa sair do host físico.

Roteamento entre sub-redes PA

Em contraste com o HNVv1 que alocou um endereço IP PA para cada Sub-rede Virtual (VSID), o HNVv2 agora usa um endereço IP PA por membro da equipe NIC Switch-Embedded Teaming (SET). A implantação padrão pressupõe uma equipe de duas NIC e atribui dois endereços IP PA por host. Um único host tem IPs PA atribuídos da mesma sub-rede lógica do Provedor (PA) na mesma VLAN. Duas VMs locatárias na mesma sub-rede virtual podem, de fato, estar localizadas em dois hosts diferentes que estão conectados a duas sub-redes lógicas de provedor diferentes. A HNV construirá os cabeçalhos IP externos para o pacote encapsulado com base no mapeamento de CA-PA. No entanto, ele depende da pilha TCP/IP do host para realizar ARP para o gateway PA padrão e depois cria os cabeçalhos Ethernet externos com base na resposta do ARP. Normalmente, essa resposta ARP vem da interface SVI no switch físico ou roteador L3 onde 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 clientes exigirá comunicação do ambiente HNV para recursos que não fazem parte do ambiente HNV. Os gateways de virtualização de rede são necessários para permitir a comunicação entre os dois ambientes. As infraestruturas que requerem um gateway HNV incluem nuvem privada e nuvem híbrida. Basicamente, os gateways HNV são necessários para o roteamento de Camada 3 entre redes internas e externas (físicas) (incluindo NAT) ou entre diferentes sites e/ou nuvens (privadas ou públicas) que usam um túnel VPN IPSec ou GRE.

Os gateways podem ter diferentes formatos físicos. Eles podem ser criados no Windows Server 2016, incorporados a um switch Top of Rack (TOR) que atua como gateway VXLAN, acedidos através de um IP virtual (VIP) anunciado por um balanceador de carga, integrados noutros equipamentos de rede existentes, ou podem ser um novo equipamento de rede autónomo.

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

Encapsulamento de pacotes

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

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

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

As autoridades de certificação mantêm a topologia de rede do cliente, que é virtualizada e dissociada da topologia e dos endereços de rede física subjacentes reais, conforme implementado pelos PAs. O diagrama a seguir mostra a relação conceitual entre CAs de máquina virtual e PAs de infraestrutura de rede como resultado da virtualização de rede.

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

No diagrama, as máquinas virtuais do cliente estão a enviar pacotes de dados no espaço CA, que atravessam a infraestrutura de rede física por meio das suas próprias redes virtuais, ou "túneis". No exemplo acima, os túneis podem ser considerados como "envelopes" em torno dos pacotes de dados da Contoso e da Fabrikam com rótulos de remessa verdes (endereços PA) a serem entregues do host de origem à esquerda para o host de destino à direita. A chave é como os hosts determinam os "endereços de remessa" (PAs) correspondentes às CAs da Contoso e da Fabrikam, como o "envelope" é colocado ao redor dos pacotes e como os hosts de destino podem desempacotar os pacotes e entregar corretamente às máquinas virtuais de destino da Contoso e da Fabrikam.

Esta analogia simples destacou os principais aspetos da virtualização de rede:

• Cada autoridade de certificação de máquina virtual é mapeada para um PA de host físico. Pode haver várias ACs associadas ao mesmo PA.

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

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

Como resultado, o mecanismo para virtualizar a rede é virtualizar os endereços de rede usados pelas máquinas virtuais. O controlador de rede é responsável pelo mapeamento de endereços e o Host Agent mantém o banco de dados de mapeamento usando o esquema MS_VTEP. A próxima seção descreve o mecanismo real de virtualização de endereços.

Virtualização de rede através da virtualização de endereços

O HNV implementa redes de locatários sobrepostas usando o NVGRE (Network Virtualization Generic Routing Encapsulation) ou o VXLAN (Virtual eXtensible Local Area Network). VXLAN é o padrão.

Rede Local Virtual eXtensível (VXLAN)

O protocolo Virtual eXtensible Local Area Network (VXLAN) (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 propagação de ECMP. Após o cabeçalho UDP, um cabeçalho VXLAN é anexado ao pacote que inclui um campo reservado de 4 bytes seguido por um campo de 3 bytes para o VNI (VNI Network Identifier) - VSID - seguido por outro campo reservado de 1 byte. Após o cabeçalho VXLAN, o quadro CA L2 original (sem o quadro CA Ethernet FCS) é acrescentado.

Encapsulamento de roteamento genérico (NVGRE)

Esse mecanismo de virtualização de rede usa o Generic Routing Encapsulation (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 PA de origem e destino apropriados, além do ID de sub-rede virtual, que é armazenado no campo Key do cabeçalho GRE, como mostra a Figura 7.

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

O ID da Sub-rede Virtual permite que os hosts identifiquem a máquina virtual do cliente para qualquer pacote, mesmo que 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 mostra a Figura 7.

A partilha do PA tem um grande impacto na escalabilidade da rede. O número de endereços IP e MAC que precisam ser aprendidos pela infraestrutura de rede pode ser substancialmente reduzido. 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 será reduzido por um fator de 30.Os IDs de sub-rede virtual incorporados nos pacotes também permitem uma correlação fácil de pacotes com os clientes reais.

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

Com o Windows Server 2016 e posterior, a HNV suporta totalmente NVGRE e VXLAN prontos para uso; ele NÃO requer atualização ou compra de novo hardware de rede, como NICs (adaptadores de rede), switches ou roteadores. Isso ocorre porque esses pacotes no fio são pacotes IP regulares no espaço PA, o que é compatível com a infraestrutura de rede atual. No entanto, para obter o melhor desempenho, use NICs suportadas com os drivers mais recentes que suportam descarregamentos de tarefas.

Exemplo de implantação multilocatária

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

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

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

• A Contoso Corp executou 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 executou 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.

Vamos supor que o provedor de serviços de hospedagem tenha criado anteriormente a rede lógica do provedor (PA) através do controlador de rede para corresponder à sua topologia de rede física. O controlador de rede aloca dois endereços PA IP a partir do prefixo IP da sub-rede lógica onde os hosts estão conectados. O controlador de rede também indica a tag VLAN apropriada para aplicar os endereços IP.

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

Ambas as empresas recebem a seguinte ID de sub-rede virtual (VSID) pelo controlador de rede, conforme indicado abaixo. O agente anfitrião em cada um dos hosts Hyper-V recebe os endereços IP PA alocados pelo controlador de rede e cria duas vNICs de host PA num compartimento de rede não padrão. Uma interface de rede é atribuída a cada um desses vNICs de host onde o endereço IP do PA é atribuído, conforme mostrado abaixo:

• VSID e PAs da Contoso Corp: VSID é 5001, SQL PA é 192.168.1.10, Web PA é 192.168.2.20

• VSID e PAs de máquinas virtuais da Fabrikam Corp: VSID é 6001, SQL PA é 192.168.1.10, Web PA é 192.168.2.20

O Controlador de Rede canaliza toda a política de rede (incluindo o mapeamento de CA-PA) para o Agente de Host SDN, que manterá a política num armazenamento persistente nas tabelas da base de dados OVSDB.

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

• A máquina virtual faz ARP para o endereço MAC de destino 10.1.1.11.

• A extensão VFP no vSwitch interceta esse pacote e o envia para o SDN Host Agent

• O SDN Host Agent procura em seu repositório de políticas o endereço MAC para 10.1.1.11

• Se um MAC for encontrado, o Host Agent injetará uma resposta ARP de volta para a 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 CA Ethernet e IP corretos e o envia para o vSwitch

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

• O mecanismo VFP executa a correspondência de regras ou pesquisa de tabela de fluxo para cada camada (por exemplo, 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 de CA-PA e executa o encapsulamento.

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

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

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

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

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

• O VFP processa o pacote através de suas camadas VFP e cria uma nova entrada de fluxo na tabela de fluxo unificada do VFP.

• O mecanismo VFP corresponde às 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 utiliza as configurações de política HNV da Fabrikam Corp. Como resultado, com o HNV, as máquinas virtuais da Fabrikam Corp e da Contoso Corp interagem como se estivessem nas suas intranets originais. Eles nunca podem interagir uns com os outros, mesmo que estejam usando os mesmos endereços IP.

Os endereços separados (CAs e PAs), as configurações de diretiva dos hosts Hyper-V e a conversão de endereços entre a CA e o PA para o tráfego de entrada e saída da máquina virtual isolam esses conjuntos de servidores usando a chave NVGRE ou a VNID VLXAN. Além disso, os mapeamentos e a transformação de virtualização separam a arquitetura de rede virtual da infraestrutura de rede física. Embora Contoso SQL e Web e Fabrikam SQL e Web residam em suas próprias sub-redes IP da CA (10.1.1/24), sua implantação física acontece 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.

Hyper-V arquitetura de virtualização de rede

No Windows Server 2016, o HNVv2 é implementado usando a Plataforma de Filtragem Virtual (VFP) do Azure, que é uma extensão de filtragem NDIS dentro do Comutador Hyper-V. O conceito-chave do VFP é o de um mecanismo de fluxo de Match-Action com uma API interna exposta ao SDN Host Agent para programação de políticas de rede. O próprio Agente de Host SDN recebe a diretiva de rede do Controlador de Rede através dos 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 VFP, mas também políticas adicionais, como ACLs, QoS e assim por diante.

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

• vComutador

  • Gerenciamento externo de NIC

  • Descarregamentos de hardware da NIC

  • Regras de encaminhamento global

  • Porto

    • Camada de encaminhamento de saída para fixação de cabelo

    • Listas de espaços para mapeamentos e pools NAT

    • Tabela de fluxo unificada

    • Camada VFP

      • Tabela de fluxo

      • Grupo

      • Regra

        • As regras podem referenciar espaços

No VFP, uma camada é criada por tipo de política (por exemplo, Rede Virtual) e é um conjunto genérico de tabelas de regras/fluxo. Ele não tem nenhuma funcionalidade intrínseca até que regras específicas sejam atribuídas a essa camada para implementar tal funcionalidade. A cada camada é atribuída uma prioridade e as camadas são atribuídas a uma porta por prioridade ascendente. 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 extensão VFP é a seguinte:

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

• Encaminhamento

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

O VFP suporta encaminhamento MAC interno para tipos de encapsulamento NVGRE e VXLAN, bem como encaminhamento externo baseado em VLAN MAC.

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

A política de HNV é programada pelo agente anfitrião. Cada adaptador de rede de máquina virtual é configurado com um endereço IPv4. Essas são as CAs que serão usadas pelas máquinas virtuais para se comunicar entre si e são transportadas nos pacotes IP das máquinas virtuais. O HNV encapsula o quadro CA em um quadro PA com base nas políticas de virtualização de rede armazenadas na base de dados do agente do host.

Figura 9: Arquitetura HNV

Resumo

Os datacenters baseados em nuvem podem oferecer muitos benefícios, como escalabilidade aprimorada e melhor utilização de recursos. Para realizar esses benefícios potenciais, é necessária uma tecnologia que aborde fundamentalmente as questões de escalabilidade multilocatário em um ambiente dinâmico. A HNV foi projetada para resolver esses problemas e também melhorar a eficiência operacional do datacenter, desacoplando a topologia de rede virtual para a topologia de rede física. Baseando-se num padrão existente, a HNV funciona no datacenter atual e opera com a sua infraestrutura VXLAN existente. Os clientes com HNV agora podem consolidar seus datacenters em uma nuvem privada ou estender perfeitamente seus datacenters para o ambiente de um provedor de servidor de hospedagem com uma nuvem híbrida.

Ver também

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

Tipo de conteúdo	Referências
Recursos da Comunidade	- Blog de arquitetura de nuvem privada - Faça perguntas: cloudnetfb@microsoft.com
RFC	- Rascunho de RFC NVGRE - VXLAN - RFC 7348
Tecnologias relacionadas	- Para obter Hyper-V detalhes técnicos da Virtualização de Rede no Windows Server 2012 R2, consulte Hyper-V detalhes técnicos da Virtualização de Rede - Controlador de rede