Temos um aplicativo personalizado e MUITO personalizado que é executado em um servidor Windows 2008R2. Sua função principal é conectar-se a muitas dezenas de milhares de endereços IP o mais rápido possível e interrogar uma porta TCP específica - essencialmente um scanner de rede, mas altamente personalizado para nossos requisitos. Não há NAT entre o servidor e os endereços de destino, e o aplicativo não consome muita quantidade de memória ou CPU.
O aplicativo (baseado no .NET) é otimizado e estamos confiantes de que o código é o mais adequado possível. No entanto, a taxa na qual o aplicativo pode se mover através dos endereços IP parece estar limitada a uma combinação da pilha TCP do Windows e do hardware em que está sendo executado - no momento em que está em uma caixa de classe baixa, mal-servidor.
Como o desempenho deste aplicativo é primordial, estamos planejando transferi-lo para um novo servidor com especificações mais altas, provavelmente um HP DL360 G8 . No entanto, poderíamos potencialmente executar várias instâncias do aplicativo em máquinas separadas simultaneamente e, portanto, gostaríamos de explorar a opção de usar o novo servidor como um host virtual.
Provavelmente estaríamos usando o VMWare ESXi, com o Hyper-V como uma opção alternativa. No entanto, não tenho certeza se o aplicativo de pacote intensivo, em execução em máquinas virtuais no servidor, simplesmente moveria o gargalo para o hipervisor?
O DL360 possui 4 NICs: poderíamos "conectar" 4 máquinas virtuais a cada uma das 4 NICs e executá-las em paralelo. O VMWare / Hyper-V efetivamente passa o tráfego diretamente para a NIC, dando desempenho de rede "nativo" ou existe um elemento de tradução entre o SO guest e o hardware que poderia causar um gargalo de pacotes no hypervisor?
Para o hyper-v: depende. Você quer ir com SR-VIO enredado na placa de hardware, a rede virtual e - o NIC. Caso contrário, todos os pacotes passam por um comutador virtual, o que significa sobrecarga. Com uma placa de rede decente, isso resultará em uma fila de hardware atribuída à máquina virtual, que é tão rápida quanto em uma camada de virtualização.
No VMware você também pode fazer o SR-IOV, tenha em mente que requer uma placa de rede que ofereça suporte a ele. Uma boa visão geral de SR-IOV por Scott Lowe, se você não estiver familiarizado com isso. O VMware também oferece a opção de fazer "DirectPath I / O", onde você dá acesso direto a um dispositivo pci, pesquisa por "DirectPath" neste PDF para mais informações. Também é importante notar que você pode experimentá-lo no VMware sem usar o DirectPath ou SR-IOV, o desempenho é muito bom, desde que você use o driver convidado VMXNET3.
Nós fizemos coisas semelhantes em RHEV (ou simplesmente KVM) usando SRIOV ou se você estiver usando Cisco UCS - com VMFEX - você precisa dos cartões Palo nos blades para este.
Implementações muito grandes em ambos os casos (5 números de servidores) funcionando muito bem por alguns anos.