Controlador RAID IBM SR-BR10i muito lento com o VMware ESXi

Question

Estou transferindo uma máquina virtual de um host ESXi para outro usando o SSH em ambos os servidores ESXi.

Mas é muito lento, é uma enorme imagem de disco de 750GB .vmdk, a VM está parada (com tempo de inatividade) e com uma taxa de velocidade de 5,5MB / s, levará mais de um dia para concluir a mudança.

Estou sentindo falta de algo?

myvm.mydomain.com-flat.vmdk                 26%  200GB   5.4MB/s 29:09:06 ETd

Hardware importante no servidor ESXi:

Supermicro X9SCM-F
Intel 82574L Gigabit Controller
IBM SR-BR10i RAID Controller
2x WD Velociraptor WD1000DHTZ (RAID1 mode from controller)

Outro ponto: eu criei e sincronizei a matriz RAID antes de iniciar a migração da VM.

Obrigado por qualquer ajuda,

    

Answer 1

Se você acha que a cópia está lenta, você ainda não viu a VM funcionar . O maior problema é que seu controlador está com falta de uma BBU e o ESXi está fazendo muitas gravações síncronas (onde o cache de gravação do controlador ou do disco, que de outra forma poderia ter sido usado, é contornado para garantir a consistência dos dados).

Adicione uma BBU (se disponível como opção) ou substitua o controlador por um modelo usando BBWC / FBWC. Ou, se você não se importar com a integridade dos dados (lembre-se de que isso pode resultar na perda de todo o armazenamento de dados se o host perder energia em um momento inoportuno), você poderá habilitar o cache de gravação mesmo para gravações síncronas usando lsiutil . Um cara até fez uma compilação para o ESXi , então você provavelmente nem precisa reiniciar para outro SO para testá-lo .

Além disso, as operações internas scp / cp do ESXi são bastante lentas , você deve escolher uma abordagem diferente:

• For performance and data placement reasons, do not use scp or cp; instead, use vmkfstools, the Virtual Machine Importer tool from VMware, or the SDK APIs to manipulate your virtual disks. You should see very significant performance improvements if you use the recommended tools.

Se você não puder usar uma das ferramentas mencionadas, considere o FastSCP da Veeam , que também é significou melhorar o desempenho da cópia do SCP.

    

Answer 2

O ESXi não foi projetado para ser usado como um propósito geral * nux, o VMWare raramente incentiva o uso da linha de comando e, quando o fazem, para tarefas específicas. Como tal, a interface da linha de comandos está bastante esgotada, tanto em termos de memória, IO e partilha de CPU. Você está tratando isso como um sistema operacional de propósito geral, pedindo que ele faça algo bastante intensivo e, portanto, não estou realmente surpreso que ele esteja funcionando mal, não será culpa do seu subsistema de disco.

Se você usa um método de transferência compatível, tenho certeza de que será mais feliz.

Editar - Ah, e acabei de perceber que esses discos não são 100% do ciclo de trabalho, ou seja, eles não foram projetados para funcionar 24 horas por dia, 7 dias por semana, isso aumentará significativamente sua probabilidade de falha. Você estava pensando em apenas executar este servidor por cerca de 12 horas por dia?

    

Answer 3

Por uma razão desconhecida (para mim), o SCP entre hosts EXSi ( livre ) é terrivelmente lento. A solução alternativa para esse problema que uso é transferir com o SCP a VM para a máquina não virtual e, em seguida, o SCP para o host ESXi de destino. Não é muito inteligente, mas consigo alterar a transferência de velocidade para 5MB / s para 80MB / s . Eu tive a mesma transferência lenta com o Veeam FastSCP, e o vmkstools não funcionou para mim (eu não tenho um armazenamento compartilhado para os convidados), então eu não poderia pensar em uma solução melhor.

Se alguém puder explicar porque o SCP entre o EXSi ( versão gratuita ) Hosts é tão terrivelmente lento, eu ficarei grato.