Para que as maquinas virtuais criadas pelo Hyper-V possam acessar (e também para que sejam acessadas) a rede é importante entender como funcionam as configurações dos switchs virtuais de rede e sua arquitetura. Nesta parte vamos entender melhor como funciona o processo.
Na arquitetura do Hyper-V a única forma de acessar as maquinas virtuais é através de serviços de rede. Diferente do Virtual PC e demais outros produtos de virtualização que utilizam mecanismos de compartilhamento de pastas, etc. o Hyper-V permite apenas o acesso às mesmas através da placa de rede, da mesma forma que o usuário está acostumado a acessar serviços de rede. Por este motivo não é possível realizar operações de Copiar / Colar através da console da máquina virtual com o Explorer do servidor de virtualização.
Durante o processo de instalação do serviço do Hyper-V são listadas todas as placas de rede disponíveis no sistema operacional. Neste momento você pode compartilhar a placa de rede com as maquinas virtuais e utilizar para gerenciamento. Mesmo que você não marque esta opção é possível acessar através da console do Hyper-V Manager e selecionar a opção ao lado direito chamada de Virtual Switch Manager:
Neste momento voc
ê pode criar 3 tipos de switches virtuais, cada um com características próprias:
Durante a criação do Switch Virtual é obrigatório fornecer um nome para o mesmo. A recomendação é que, se você tiver vários servidores de virtualização na sua empresa, procure padronizar o nome dos switches virtuais entre os servidores. Um dos motivos é evitar possíveis erros ao efetuar a movimentação de máquinas virtuais entre os Hosts (servidores de virtualização). Outro motivo é que, ao efetuar um export de máquina virtual para outro servidor, caso o nome do switch virtual seja diferente entre os mesmos então pode ser necessário reconfigurar a rede da máquina virtual.
As maquinas virtuais, por padrão, não tem acesso a placa de rede física. Isto significa que se você tiver no seu servidor uma placa do Fabricante CONTOSO modelo XPTO2000 então o Hyper-V não vai apresentar para a máquina virtual a mesma placa, mas sim uma VMBus Network Adapter. Isto significa que você não precisará instalar o driver da placa de rede dentro da máquina virtual (basta instalar no Host). A máquina virtual consegue utilizar a rede, entretanto não conseguirá mudar parâmetros de IRQ e DMA da placa física.
O Hyper-V pode criar 2 tipos de placa de rede para a máquina virtual:
Um dos motivos de se evitar o uso de Legacy Network Adapter é a penalidade para processamento extra no servidor de virtualização. Se você possui várias maquinas virtuais que não suportem Integration Services (e por consequência não sejam suportadas pelo Hyper-V) a máquina virtual abre um processo em User Mode no host (servidor de virtualização) a cada acesso feito ao hardware. Esta transição de Kernel Mode da máquina virtual para User Mode no Host impacta em penalidades extras de processamento. Na prática se você tiver 2 servidores, o primeiro com 10 maquinas virtuais Windows Server 2008 R2 com 1 Virtual processor e 1GB de RAM, e outro servidor com 10 maquinas virtuais Windows NT 4.0 com 1 Virtual Processor e 1GB de RAM, então este último vai demandar mais processamento que o outro servidor.
– VLAN no Hyper-V
Você pode utilizar o recurso de VLAN nas placas de rede da máquina virtual, ao acessar as propriedades da mesma pelo Hyper-V Manager. Ao configurar o VLAN ID você estará identificando uma máquina para pertencer a uma VLAN em particular. A VLAN ID é encapsulada em um frame ethernet, permitindo que várias maquinas virtuais usem a mesma placa de rede para se comunicar com diferentes VLANs simultaneamente. É importante salientar que a configuração de VLAN ID não deve ser feita nas configurações da placa de rede física. Entretanto é possível ter a placa de rede do host físico em uma VLAN e as maquinas virtuais em outras VLANs, entretanto apenas para configurar o VLAN ID da VM é que deverá ser feito através das configurações da máquina virtual:
Para maquinas virtuais que demandem muito acesso a rede (como por exemplo servidores de arquivo e e-mail) talvez seja necessário ter mais de uma placa de rede no servidor físico. Em muitos casos com maquinas virtuais de grande acesso a rede é necessário ter 1 switch virtual para cada máquina virtual. Além disso este cenário pode complicar mais se este servidor de virtualização estiver trabalhando com Failover Clustering. Ao dimensionar a quantidade de placas e função das mesmas podemos chegar ao seguinte cenário:
Para saber se você precisa de mais placas de rede para o ambiente basta adicionar o contador de performance abaixo:
Network Interface(*)output Queue Lenght
Normalmente em cenários quando há a necessidade de se aumentar o throughput de rede são utilizados NIC Teaming. Para quem não tem familiaridade o recurso de NIC Teaming depende do fabricante e modelo da placa. Em tese você pode ter 2 ou mais placas de rede (ou portas de rede em caso de placas de rede multiporta) trabalhando em Failover (quando uma falhar a outra porta / placa assume o trafego de rede) ou em performance (2 ou mais placas / portas trabalhando agregando velocidade). Entretanto pelo fato do recurso de NIC Teaming ser uma implementação do fabricante então a Microsoft não oferece suporte ao mesmo (somente o fabricante). Isto é importante, pois caso utilize NIC Teaming através do recurso da placa de um fabricante em conjunto com o Hyper-V podem ocorrer problemas de conectividade. Para se informar melhor sobre estas recomendações leia o artigo abaixo:
Microsoft Support Policy for NIC Teaming with Hyper-V
http://support.microsoft.com/kb/968703
Entretanto se você utiliza o Windows Server 2012 existe o recurso de NIC Teaming, nativo no sistema operacional. Isto significa que é possível fazer NIC Teaming via software entre placas de rede distintas (não há necessidade do driver suportar ou de se trabalhar com modelos idênticos.). Outro ponto importante é que o NIC Teaming do Windows Server 2012 pode ser feito com ou sem um switch que suporte trunking.
O cenário que permite uma nova realidade são as placas 10gbps Ethernet, e neste ponto fazem total sentido para servidores de virtualização. O motivo disto é que um switch virtual de 1gbps pode ser insuficiente para as maquinas virtuais, e pode exigir que se tenha várias placas no mesmo servidor físico. Isto leva a outro problema, pois muitos servidores não possuem capacidade grande de expansão de slots para as placas de rede.
A escolha correta de uma placa de rede pode trazer benefícios específicos para um ambiente virtualizado, e isto justifica o fato de muitas placas novas para servidores terem um custo mais elevado que placas de rede simples. De acordo com o tipo de recurso disponível é possível habilitar maior desempenho de rede para as maquinas virtuais e para o host (servidor de virtualização)
– Chimney / TCP Offload
Normalmente em uma comunicação de rede entre maquinas é utilizado o processador da máquina para analisar a integridade dos pacotes TCP, demandando CPU extra. Quando a placa suporta o recurso de TCP Offload é possível passar esta tarefa para o processador da placa, aliviando o processador do servidor de virtualização. Em um ambiente virtualizado o trafego TCP/IP em uma máquina virtual pode ser descarregado para uma placa física de rede no servidor host.
Os benefícios são a redução de CPU, “descarregamento”(offload) da rede para melhorar o desempenho, além de oferecer suporte ao Live Migration (melhorando o tempo de transferência de dados). Entretanto é importante salientar que nem todos os cenários são beneficiados. Seu uso tem aproveitamento em conexões duradouras com transferência de dados grandes e com aplicações que suportem pre-post de buffer. Além disso o hardware compatível com o Chimney suporta um número fixo de conexões “offload” – compartilhado entre as maquinas virtuais.
Caso seu hardware suporte TCP offload engine então voce executar o NETSH para habilitar o mesmo: netsh int tcp set global chimney = enabled
Outros recursos de Offload como Checksum calculation, IPSec offload e Large Send Offload (LSOv1 e LSOv2) e Large Receive Offload, por exemplo, podem ajudar bastante no alivio de carga de processamento extra para o servidor de virtualização.
– Virtual Machine Queue
O Virtual Machine Queue (VMQ) permite que a placa de rede acesse pacotes diretamente da memória da máquina virtual. Desta forma o buffer do dispositivo da máquina virtual é atribuído a uma das filas (Queue). Isto significa evitar cópias de pacotes no VSP (Virtual Service Parent) e pesquisas de rota no switch virtual (de acordo com o ID da fila da VMQ). Na prática permite que a placa de rede essencialmente apareça como várias placas de rede no servidor físico (filas / queue).
Em placas 10gbps é mais fácil de encontrar o recurso e traz uma série de benefícios de desempenho. O host (servidor de virtualização) não tem mais dados de DMA do dispositivo em seu próprio buffer, resultando em um caminho mais curto para I/O (entrada e saída).
Teste de desempenho tomando como exemplo placas de rede Intel© com suporte a VMQ
– Jumbo Frames
O frame de dados transmitido entre maquinas possui um determinado tamanho. Quando se tem necessidade de transmitir pacotes de dados grandes é muito mais vantajoso aumentar o tamanho deste frame, reduzindo a carga de processamento (CPU). Ao habilitar Jumbo Frames no Host (servidor de virtualização) você pode ter ganhos de performance, em especial quando se utiliza iSCSI (tanto para o servidor de virtualização quanto para as maquinas virtuais). Obviamente o recurso de Jumbo Frames depende da placa de rede suportar, e todo meio intermediário de comunicação também deve suportar (isto inclui switches de rede).
No Hyper-V o suporte é oferecido tanto para o virtual switch quanto para a placa de rede virtual, desde que o Integration Services esteja instalado. Caso tenha configurado tudo você pode testar a partir da máquina virtual, executando um comando PING com um lenght (tamanho) maior e sem fragmentação. (ex: PING –n 1 –l 8000 –f 192.168.1.1)
– Receive-Side Scaling (RSS)
O Windows Server 2008 e o Windows Server 2008 R2 suportam o RSS de forma nativa. Na prática o processamento de pacotes de rede é distribuído entre os processadores da máquina (mais uma vez vale o argumento de que em um servidor de arquivo quanto mais processadores melhor). Durante o Boot da máquina o sistema operacional analisa a velocidade e o estado da placa de rede para fazer o cálculo de distribuição. Isto significa que quanto mais rápido e melhor for a placa de rede, mais do processador será exigido. Portanto não se trata de uma via de única mão, mas dupla, portanto se você implementar placas de rede de alta performance também será necessário processadores equivalentes.
Neste ponto verifique sempre com o fabricante da sua placa de rede do servidor quanto a recomendação de quantidade de placas de rede para ambientes virtualizados. Algumas placas fazem a distribuição de interrupção entre múltiplos processadores da máquina, enquanto outras placas fazem utilização apenas de um único processador para interrupções. Infelizmente este não é uma informação fácil de achar e será necessário que você pesquise mais a fundo na documentação técnica da placa.
Em resumo: o objetivo neste tópico é entender que é importante diminuir a carga de processamento extra do servidor de virtualização, passando muitas das funções que o processador faria para a placa de rede. Entretanto fica claro que não é qualquer placa de rede que deve ser utilizada em um ambiente virtualizado, portanto dimensione muito bem as placas de rede e os meios intermediários (switches de rede). Infelizmente muitos administradores de rede não dão a devida importância para a rede, podendo se tornar um ponto de gargalo de desempenho e futuros problemas.
Um dos primeiros MVPs (Most Valuable Professional) de infraestrutura do Brasil, além de MCTS, MCITP, MCSA, MCSE, MCITP e MCT, com mais de 14 anos de experiência no mercado de infraestrutura de redes Microsoft. Atuou em muitos cases da Microsoft e hoje ocupa a posição de Especialista em Infraestrutura e Virtualização no time de Comunidades Técnicas da Microsoft Brasil. Sua missão é contribuir com os profissionais e comunidades de IT Pros a explorar as funcionalidades e recursos da plataforma Microsoft. Bom, este é o mini-cv formal do Fabio Hara. O mini-cv “informal” do Hara-san (como é mais conhecido) seria: Hara-san costuma jogar partidas lendárias de Gears of War, Call of Duty MW2, Halo:Reach, etc, nas horas de folga com seus amigos. Além disso curte bastante jogar tênis (apesar de jogar mal) e escutar um bom rock anos 80/90. Grande apreciador do Home-brewing, graças aos conhecimentos que foram aprendidos com o Dalai Lama dos Portais Colaborativos Sagrados(Roberval Ranches – mesa). Tambem gosta de treinar Aikidô, e sempre que possível costuma treinar regularmente. Certa vez me perguntaram: “Hara, o que você faz na Microsoft?”. Na epoca eu disse que divulgava novas tecnologias, produtos, etc. Hoje eu posso dizer que não é bem isso. Minha resposta hoje é: “Eu ajudo você com informações e conteúdos que te ajudem a ganhar dinheiro, ser reconhecido e voltar mais cedo para casa para ficar com a sua familia” Site: http://www.fabiohara.com.br/ Twitter: http://Twitter.com/fabiohara Bom, o Hara tambem fez uns videos bacanas no Youtube. Segue alguns deles: Fabio Hara usando Surface – parte 1 Fabio Hara usando o Surface – parte 2 Fabio Hara usando o Surface – parte 3 Fabio Hara usando o Surface – parte 4 final Container do Azure – via Fabio Hara / parte 1 Container do Azure – via Fabio Hara / parte 2
You must be logged in to post a comment.
