Aplicativo "não suportado" em uma VM?


10

Compramos algum software de uma empresa pequena, é um gerenciador de fluxo de trabalho de conteúdo de vídeo de 32 bits do Windows, houve alguma personalização por eles.

Trabalhamos bem há mais de um ano executando esse código em uma VM VMWare ESXi 4.1u2 em W2K3EE-32 bits (é nisso que eles suportam a execução).

Em seguida, eles atualizaram seu código há cerca de um mês e começamos a ver uma das vCPUs periodicamente fixando em 100%, a segunda vCPU está bastante inativa, digamos 5-7% - então assumimos que o código está mal encadeado e os contatamos sobre isto.

Agora, eles voltam para nós dizendo que o código deles não funciona em uma VM, que conhecem esse requisito há 18 meses ou mais e que desejam que façamos o V2P. Eles dizem que só veem esse problema quando executam dentro de VMs. Eu tenho uma ligação com o programador sênior agendada em algumas horas para discutir.

Agora, felizmente, temos alguns exames físicos nos quais podemos fazer isso, um pouco demorados, mas factíveis.

Minha pergunta, no entanto, é que, como essa VM não toca em nenhum hardware diretamente, está em um host muito moderno e na verdade tem requisitos muito baixos (2 x vCPU, 4 GB, vdisk de inicialização de 20 GB, vdisk de 100 GB, vdisk de dados de 100 GB, vNIC única e nada mais) poderia haver o problema de executá-lo em uma VM, se houver um?

Obviamente, estou perseguindo isso com eles, mas me perguntei se mais alguém encontrou um aplicativo regular, que de alguma forma se comporta mal em uma VM, mas não em uma física.


Os dois vCPU estão puxando da mesma CPU? Você tem a configuração de que cada núcleo real é mapeado diretamente para uma vCPU? Você está fazendo algo engraçado como ter o hyper-threading ativado nas CPUs? Estas são algumas perguntas que devem ajudar a resolver qualquer coisa que possa causar lentidão ao seu final, que você possa resolver. Você provavelmente terá uma idéia melhor depois de conversar com o programador sênior sobre como resolver os problemas que talvez surjam por executá-lo em uma VM ou saberá com certeza se eles estão apenas fazendo errado. Pode ser que o código seja escrito em java.
Wilshire

Estou deixando o ESXi fazer suas próprias coisas em termos de agendamento de processos, e no hyperthreading do Xeons da série 55xx não é considerado 'engraçado', funciona e é muito útil - ah, e o .NET 3.5 do código, a propósito.
Chopper3

Eu sei que o MySQL Cluster aparentemente também não 'oficialmente' funciona em um ambiente virtualizado. Razão? Não sei! : P
Ben Ashton

Respostas:


3

Embora eu não possa falar por esse fornecedor ou pelo pacote de software, trabalhei para um grande fornecedor (multinacional), em que um dos softwares que eles vendiam tinha problemas conhecidos muito específicos ao executar no VMware.

Nesse caso, um problema pode causar o impasse do software e o outro pode causar corrupção de dados. Como tal, os clientes não foram aconselhados a executar o software em um ambiente virtual. Alguns ainda o fizeram, e em todos os casos que eu conhecia, eles tiveram um ou ambos os problemas.

Portanto, embora seja raro, pode haver casos em que o software não funciona como o esperado no VMware.

Embora eu saiba que isso não ajuda diretamente no seu problema, ele mostra que o VMWare nem sempre é o sistema perfeito.

Nota de rodapé: nesse caso, o fornecedor conseguiu trabalhar com o VMware para encontrar resoluções (algumas correções de código, algumas alterações na configuração do VMWare) e agora possui algumas orientações (muito específicas) sobre como executar o software no VMWare.


É exatamente o tipo de coisa que me deixa triste, mas grato por ouvir - como mencionei a Janne em sua resposta, nos acostumamos a trabalhar corretamente em VMs que encontrar um conjunto tão estranho de circunstâncias me deixou um pouco confuso por ser honesto , então ouvir de você que não estou sozinha nisso é pelo menos reconfortante. Ainda não ouvi nada de positivo do fornecedor do software, mas sei que eles estão investigando o problema, mas não consigo imaginar uma correção por um mês ou mais, infelizmente. Obrigado novamente.
Chopper3

3

Com o ESX v5 e o limite da VM Monster (32vCPU 1TB RAM), o número de aplicativos com problemas na VM está diminuindo. A maioria dos que experimentei são: - confiar no tempo para ser linear (processos ou aplicativos em tempo real que precisam ter tempo linear ... isso geralmente pode ser ajustado) - aplicativos que causam muitas interrupções de hardware ou alternância de contexto

Na maioria dos casos, você deve solicitar ao seu representante de vmware que fale com esses caras. Eu acredito que o vmware ainda tem uma equipe de pessoas dedicadas a fazer as coisas funcionarem (eles tinham um laboratório de suporte apenas para isso nos primeiros dias).

Quanto a uma solução, tive um problema semelhante com a VM com alto uso de CPU (mas o host possui muitos recursos de CPU gratuitos). Corrigimos o problema migrando para um servidor com uma CPU Nehalem e alterando o nível de compatibilidade da CPU no EVC (se você tiver um cluster com DRS / HA)


Obrigado pela sua resposta - muito gentil da sua parte quando isso realmente não é um tipo de pergunta em preto e branco. Seus exemplos são muito úteis, vou voltar e examinar a alternância de contexto em particular. Ah, e todos os nossos servidores estão exatamente na mesma CPU (X5690) com o EVC configurado de maneira uniforme, mas obrigado novamente.
Chopper3

2

Eu já vi um problema semelhante com o VMware ESX + Debian 6 + OpenLDAP 2.4.x (qualquer que seja a versão exata do OpenLDAP, é apt-gettable ...).

Nas operações diárias, funciona bem, mas coisas como importar um arquivo LDIF muito grande com 400.000 entradas são muito lentas (50-100x mais lento que nos servidores físicos). Além disso, com o benchmarking de alto volume e longa duração, tudo está indo bem com o tempo de resposta de alguns milissegundos, mas ocasionalmente existem picos estranhos que variam de 500 a 25.000 (!) Milissegundos.

Com servidores físicos, não consigo reproduzir esses problemas. E sim, passei cerca de três semanas tentando isolar o problema, ajustando todos os tipos de parâmetros, desde parâmetros do sistema operacional, passando valores para valores BerkeleyDB ... nada ajudou.


Muito obrigado por compartilhar suas experiências, não posso dizer que não acho essa coisa toda um pouco estranha - sou um nerd de virtualização de experiências e estou tão acostumado com as coisas que funcionam que para encontrar um aplicativo que faça isso abalou minhas crenças de certa forma, por isso é bom saber que não estou em uma posição isolada. Obrigado.
Chopper3

1
Outros dois exemplos: Atlassian diz que ambos Jirae Confluencenão são recomendados para execução em um ambiente VM (ware). Deve haver um padrão para essas exceções, mas ainda não descobri o que pode ser. Minha instalação do OpenLDAP não é muito intensiva de E / S (gravação de 3 MB / se não há muitos IOPS em picos durante o benchmark), ela usa talvez 20-40% da CPU e cerca de 150 MB de RAM. Não deve ser muito difícil de manusear. Talvez tenha algo a ver com o encadeamento, mas o vmstat informa que as alternâncias de contexto etc estão no nível normal.
Janne Pikkarainen

Minha teoria atual é que isso tem algo a ver com a manutenção do tempo do SO. A VMware teve todos os tipos de problemas estranhos de clock no passado e, mesmo agora, às vezes é necessário passar alguns tsc=pitparâmetros elegantes durante a inicialização, e pelo menos o OpenLDAP é MUITO sensível à precisão do clock do sistema. Talvez eu deva rastrear todos os aplicativos problemáticos e ver se todos eles usam muito gettimeofday()ou pouco.
Janne Pikkarainen

Obrigado novamente, você está certo sobre o tempo na VM, está inerentemente em todo o lugar, então eu entenderia isso, mas não posso deixar de pensar que, mesmo que isso fosse um problema, seria um problema muito rápido para nossos fornecedores identificam seu código, lembre-se de que não é realmente um aplicativo que demanda tempo, apenas captura o conteúdo do vídeo e o processa, hum. Obrigado novamente.
Chopper3
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.