Tenho uma pergunta sobre meu laboratório de testes. É mais para entender o conceito do que aplicá-lo na produção:
Tenho um ESXi com poucas VMs linux/windows configuradas e gostaria de usar o conversor VMWare para criar backups.
Para acelerar o processo decidi criar uma VM Windows no mesmo host ESXi onde instalei o Windows 7 e o VMWare Converter.
O Host possui uma placa gigabit, mas atualmente está conectado a uma porta FD de 100Mb. O Windows 7 vê um cartão de 1 GB conectado.
Quando faço o backup usando o conversor VMWare, especifico o IP do host como origem e destino, então pensei que a cópia poderia ser mais rápida do que usar meu laptop na rede.
Bem, para resumir: obtenho um desempenho terrível (4Mb/seg). Estou um pouco confuso sobre isso porque, apesar do host estar executando 100 Mb, a comunicação entre VMs e hosts não deveria (corrija-me se estiver errado) ter qualquer limitação.
Ajustei o Windows 7 para otimizar o desempenho da rede, mas obtive apenas uma pequena melhoria. ainda preciso de 4 horas para fazer backup de uma VM de 50 Gb (fina).
Além disso, gostaria de perguntar: o quadro jumbo ajudaria nisso? Eu sei que o jumbo frame precisa ser suportado de ponta a ponta, e o switch de rede onde o host está conectado atualmente não suporta isso, mas eu queria saber:
1) O host ESXi suporta frames jumbo?
2) Posso habilitá-lo de alguma forma?
3) Se eu fizer isso, acho que a transferência em massa entre as VMs e o host melhoraria, mas isso afetaria a comunicação que passa pelo switch real, já que isso não funciona?
Obrigado por ler
Responder1
Os quadros jumbo podem fazer alguma diferença, mas seus problemas de rendimento indicam um problema muito mais grave. Você pode habilitar Jumbo frames no ESXi, mas isso requer o uso das ferramentas de linha de comando vCLI - você pode encontrar instruções específicas nesteDocumento de configuração do VMware ESXi.
Existem algumas causas possíveis.
Você pode ter seus dados entrando e saindo do host ESXi - nesse caso, o Converter copiaria os dados de dentro da VM no host ESXi de volta para a interface de gerenciamento por meio de sua rede física. Dado que é um uplink de 100 Megabits, ainda espero que você obtenha alguns Megabytes/s em vez dos 4 Megabits/s relatados.
Suas NICs de host ESX podem não estar negociando corretamente as configurações de 100 Mbps/Full duplex com o switch - certifique-se de que as configurações do switch e do pNIC em seu host ESXi estejam definidas corretamente.
O conversor não é muito eficiente em termos de rendimento, mas se você estiver usando cópia de disco baseada em bloco (em vez de nível de arquivo), tudo bem (a taxa de transferência será> 50% da largura de banda máxima do link - digamos 4 Meg/seg em 100 Mbps rede, 40Meg/seg em GigE). Se a sua cópia estiver usando cópia em nível de arquivo, as coisas serão muito mais lentas.
Toda essa atividade está colocando uma quantidade razoável de carga adicional no subsistema de disco em que suas VMs estão armazenadas. Se você estiver executando tudo isso em um armazenamento bastante lento (digamos, algumas unidades SATA no RAID 5), é possível que o disco esteja se debatendo, mas para uma configuração de armazenamento saudável, esse tipo de coisa não deve ser um estresse.
Acho que o problema está na sua rede virtual - supondo que seja, você deve considerar o seguinte:
Se a sua porta de gerenciamento ESXi estiver no mesmo switch virtual que o grupo de portas de rede de produção da sua VM, o tráfego deverá retornar internamente no switch virtual. Se isso não estiver acontecendo, eu começaria a verificar se as VLANs estão configuradas nas portas\grupos de portas ou se o seu endereço IP está fazendo com que o tráfego pense que precisa sair do switch antes de voltar (por exemplo, se você tiver o Management porta em uma sub-rede diferente da rede VM e dependem de um roteador externo para permitir a comunicação). Se você suspeitar que sua rede não está fazendo o procedimento acima corretamente, você pode colocar as VMs de origem e de destino na mesma sub-rede que a porta de gerenciamento e conectá-las a um grupo de portas de VM no mesmo vSwitch que a porta de gerenciamento, então você deve obter tráfego entre os vários sistemas (a origem, a VM conversora e o host ESX) permaneça dentro dos limites do vSwitch. Mova os grupos de portas da VM em vez de mexer na porta de gerenciamento - se você cometer um erro, terá que voltar ao console físico do ESXi para consertar as coisas e é melhor evitar correr riscos com isso.
Desligue também o máximo que puder antes de começar, caso algo como um processo de backup esteja sobrecarregando toda a largura de banda da rede da porta de gerenciamento, etc.
Responder2
Desativar a criptografia SSL é uma forma de contornar esse problema. Aqui está como isso é feito:
Open the converter-worker.xml configuration file. It is located in
"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"
folder for Windows Vista or newer or in
"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"
for older Windows versions.
Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.
Ou seja, deveria ser parecido com:
...
<nfc>
<readTimeoutMs>120000</readTimeoutMs>
<useSsl>false</useSsl>
...
"Reiniciar o serviço "VMware vCenter Converter Standalone Worker"."