Não é uma questão técnica, mas válida mesmo assim. Cenário:
HP ProLiant DL380 Gen 8 com 2 CPUs Xeon E5-2667 de 8 núcleos e 256 GB de RAM executando o ESXi 5.5. Oito VMs para o sistema de um determinado fornecedor. Quatro VMs para teste, quatro VMs para produção. Os quatro servidores em cada ambiente executam diferentes funções, por exemplo, servidor da web, servidor de aplicativos principal, servidor de banco de dados OLAP e servidor de banco de dados SQL.
Compartilhamentos de CPU configurados para impedir que o ambiente de teste cause impacto na produção. Todo o armazenamento em SAN.
Tivemos algumas dúvidas sobre desempenho, e o fornecedor insiste que precisamos fornecer ao sistema de produção mais memória e vCPUs. No entanto, podemos ver claramente no vCenter que as alocações existentes não estão sendo tocadas, por exemplo: uma exibição mensal da utilização da CPU no servidor de aplicativos principal gira em torno de 8%, com o pico ímpar de até 30%. Os picos tendem a coincidir com o backup do software de backup.
História semelhante sobre RAM - a maior quantidade de utilização nos servidores é de aproximadamente 35%.
Então, estamos pesquisando, usando o Process Monitor (Microsoft SysInternals) e o Wireshark, e nossa recomendação para o fornecedor é que eles façam algum ajuste no TNS na primeira instância. No entanto, isso é além do ponto.
Minha pergunta é: como fazer com que eles reconheçam que as estatísticas da VMware que enviamos são evidências suficientes para que mais RAM / vCPU não ajudem?
--- ATUALIZAÇÃO 12/07/2014 ---
Semana interessante. Nosso gerenciamento de TI disse que devemos fazer a alteração nas alocações de VMs e agora estamos aguardando algum tempo de inatividade dos usuários corporativos. Estranhamente, os usuários de negócios são aqueles que dizem que certos aspectos do aplicativo estão sendo executados lentamente (em comparação com o que eu não sei), mas eles vão "nos informar" quando pudermos derrubar o sistema (resmungar resmunga!).
Como um aparte, o aspecto "lento" do sistema aparentemente não é o elemento HTTP (S), ou seja, o "aplicativo thin" usado por mais dos usuários. Parece que é o "cliente gordo" instala, usado pelos principais órgãos de finanças, que é aparentemente "lento". Isso significa que agora estamos considerando o cliente e a interação cliente-servidor em nossas investigações.
Como o objetivo inicial da pergunta era procurar ajuda sobre se ir pela rota do "picar", ou apenas fazer a mudança, e agora estamos fazendo a mudança, eu a fecho usando resposta do longneck .
Obrigado a todos pela sua contribuição; como de costume, o serverfault tem sido mais do que apenas um fórum - é como o sofá de um psicólogo: -)
Sugiro que você faça os ajustes solicitados. Em seguida, compare o desempenho para mostrar a eles que não faz diferença. Você pode até mesmo ir tão longe para compará-lo com a memória LESS e com a vCPU para enfatizar seu ponto de vista.
Além disso, "Estamos lhe pagando para dar suporte ao software com soluções reais, e não adivinhações".
Desde que você tenha certeza de que está dentro das especificações de sistema fornecidas.
Então, qualquer reivindicação que eles estejam fazendo em relação à exigência de mais RAM ou CPU deve ser possível fazer o backup. Como os especialistas em seu sistema, eu responsabilizo as pessoas por isso.
Pergunte-lhes detalhes.
Quais informações fornecidas no sistema indicam que mais RAM é necessária e como você interpretou isso?
Quais informações fornecidas no sistema indicam que mais CPU é necessária e como você interpretou isso?
Os dados que tenho - à primeira vista - contradizem o que você está me dizendo. Você pode me explicar por que eu posso estar interpretando isso incorretamente?
Estou interpretando essa [série de dados óbvia] para significar [interpretação óbvia]. Você pode confirmar que estou interpretando corretamente com relação ao meu problema?
Tendo lidado com o suporte no passado, fiz as mesmas perguntas. Às vezes eu estava certo e eles não estavam concentrando sua atenção no meu problema corretamente. Outras vezes, no entanto, eu estava errado e eu estava interpretando os dados incorretamente, ou não incluindo outros dados que eram importantes na minha análise.
Em qualquer caso, ambas as situações foram um benefício líquido para mim, ou aprendi algo novo que eu não conhecia antes - ou consegui que as equipes de suporte deles pensassem mais sobre o meu problema obter uma causa raiz decente.
Se a equipe de suporte não puder fornecer uma expansão lógica de seu argumento para uma base com a qual você possa ficar satisfeito (você precisa ter a mente aberta para se comprometer, seja razoável aceitar que sua interpretação dos dados está errada então deve ficar muito presente em sua resposta. Mesmo no pior cenário, você pode usar isso como base para escalonar o problema.
O importante é provar que você está usando práticas recomendadas para a alocação de seu sistema, principalmente reservas de RAM e CPU para seu servidor SQL.
Tudo isso dito, o mais fácil é fazer os ajustes solicitados, pelo menos temporariamente. Se nada mais, ele tende a fazer os fornecedores se arrastarem. Eu não posso contar o número de vezes que eu precisei fazer algo louco assim para satisfazer um técnico do outro lado da linha que é realmente o software deles não se comportando.
Para esta situação específica (onde você tem desenvolvedores de VMware e de aplicativos ou terceiros que não entendem a alocação de recursos), eu uso uma semana de métricas obtidas de vCenter Operations Manager (vCops - faça o download de uma demonstração, se necessário ) para identificar as limitações reais, os gargalos e o dimensionamento requisitos da (s) VM (s) da aplicação.
Às vezes, posso satisfazer os consumidores mais teimosos modificando as reservas de VM ou alterando prioridades para lidar com cenários de contenção; " Se a RAM | CPU estiver apertada, SUA VM terá precedência! ". Coisas ruins aconteceram quando Eu permiti que os fornecedores de software ditassem seus requisitos em meus clusters do vSphere sem uma análise real .
Mas, em geral, números e dados devem ser ganhos.
Um exemplo de algo que usei para justificar o dimensionamento de VMs para o desenvolvedor de um aplicativo do Tomcat:
Dev : A VM precisa de CPU MOAR!
Eu : Bem, a memória é o seu maior constrangimento, e aqui está um mapa de calor do seu desempenho versus tempo ... Quartas-feiras às 6 da tarde são os períodos mais estressantes, esse período de pico. Ah, e aqui está uma recomendação de dimensionamento com base nas últimas 6 semanas de métricas de produção ...
Eu costumava trabalhar em apoio - e parte do que você está perguntando soa altamente racional (e provavelmente é): mas há algumas perguntas a se fazer antes de apenas fazer o "desempenho" aprimoramento "eles estão solicitando
Os fornecedores farão 99 vezes em 100 (na minha experiência - tanto no lado do suporte quanto no lado do cliente / campo) nem lidam com problemas relacionados ao desempenho até / a menos que os sistemas correspondam ao que a documentação exige. Talvez seja um sistema que funciona 99,5% do tempo com 1 CPU e 512M de RAM - mas se os requisitos do sistema dizem 4 CPUs e 4G de RAM e você tem apenas 2 CPUs e 1G de RAM, eles estão bem dentro de seus direitos exigir mais recursos sejam atribuídos * .
É provável que eles peçam para você aumentar os recursos do sistema por causa de algo que eles encontraram no laboratório / desenvolvimento em que um problema magicamente desaparece se você cruzar um limite específico; Se este for o caso, sim, é um exemplo de depuração potencialmente pobre, mas tenha em mente que eles não têm tempo para eliminar cada possível bug / problema que surge - alguns só precisam ser trabalhado, e se for esse o caso aqui, basta ir com ele.
Há também uma chance não insignificante de que os problemas que você está vendo não façam parte do software "deles", mas um componente em que eles dependem de alguma outra fonte (fornecedor, biblioteca OSS, etc.). Eu corri para essa situação exata relacionada ao tamanho da troca, BEA WebLogic, e o Sun JRE em um cliente há alguns anos.
Em suma, trabalhe com sua equipe de suporte, aumentando conforme necessário, até encontrar uma resolução, mas não se surpreenda se algumas das sugestões / etapas / correções de depuração soarem fora do comum ou sem sentido.
* Se realmente não "precisar" desses recursos extras, você provavelmente está em um local para poder arquivar um bug de documento / RFE para versões futuras - mas não force esse caminho até que você tenha demonstrado que não é o problema em questão
^ um eBook que escrevi, você pode achar útil no tópico: < href="http://cnx.org/content/col11350/latest"> Depurando e suportando sistemas de software
Peça para escalar o ticket ou peça um representante diferente. Dependendo do fornecedor, a escalada pode ajudar se você disser que acha que o nível atual de suporte não resolve adequadamente o problema. Se eles não aumentarem, pedir um representante diferente pode ajudar, porque isso requer muito menos "justificativa", já que tudo o que precisa é não ser feliz com o atual.
Se for um fornecedor grande, basta fechar o ticket e abrir um novo no mesmo problema, pois ele pode ser encaminhado para um representante diferente, mas eu não aconselharia porque é de baixa qualidade.
Você também pode se manter firme e pedir uma explicação de como mais RAM / vCPU ajudará, ou você pode simplesmente dar mais RAM / vCPU para provar que isso não ajudará.
Vou jogar meus dois centavos. Temos tido muito sucesso com essa abordagem - resultados muito melhores e menos frustração da parte de todos. Requer muito mais esforço do que o jogo da culpa e a inclusão cega de recursos, mas também tem melhores chances de encontrar o problema subjacente.
Quando temos sérios problemas com nossos aplicativos locais que são respaldados por contratos de suporte de fornecedores, e os fornecedores começam sua dodge shuffling dance (que sempre parece incluir demandas não orientadas a dados por mais CPU ou RAM), nós tendemos a fazer estas 3 coisas:
Encaminhe a prioridade para o equivalente do sistema - eles costumam recusar, mas geralmente recuam quando você explica que é efetivamente inutilizável, mesmo que seja tecnicamente "funcional". Trate-o como um problema sério para eles resolverem. Por aqui nos referimos a isso como uma equipe de tigres, que se reúne diariamente para obter atualizações de status de todas as partes interessadas. Normalmente, o fornecedor pedirá para você alterar as coisas. Se for um sistema de produção, isso é problemático, mas se você quiser que eles o ajudem, você precisará aceitar a responsabilidade de ajudá-los a isolar o problema, por isso ajuda se você tiver um ambiente de desenvolvimento / teste onde possa executar testes.
Diga ao fornecedor que você deseja que ele replique seu ambiente, para que ELES possam isolar o problema em seu laboratório. Eles podem até mesmo hospedar coisas em algum ambiente de nuvem, se necessário. Não precisa ser uma correspondência exata do seu ambiente, embora isso seja ideal. O ponto é que você quer que o FORNECEDOR esteja tentando replicar seu problema ativamente, para que eles possam testar suas adivinhações no sistema deles, e não no seu. Peça-lhes os diagramas, especificações, etc. desse ambiente replicado para se certificar de que estão fazendo isso.
Forneça a eles (com NDA, é claro) o seu conjunto de dados real para que eles possam executá-lo / reproduzi-lo de verdade em vez de adivinhar. Em nosso caso, a maioria dos problemas de aplicativos fornecidos pelo fornecedor (transitórios e crônicos) frequentemente resultam em problemas com os bancos de dados fornecidos pelo fornecedor. Eu não posso contar o número de vezes que fizemos isso e eles finalmente identificaram o problema em algo inesperado nos dados reais - artefatos estranhos de upgrades de aplicativos 2 anos atrás, em que algo não se converteu corretamente; registros antigos expondo um problema com as configurações do GC; as consultas não funcionam corretamente porque NOSSOS valores de dados quebram alguma rotina de transmog no código do fornecedor, etc. Coisas que nunca seríamos capazes de identificar por conta própria.
Fizemos isso com vários fornecedores nos últimos anos, e eles são inicialmente muito resistentes em fazer do nosso jeito. No entanto, depois que ele funciona, ele sempre aparece como um destaque positivo nas revisões trimestrais que mantemos com nossos fornecedores. E isso ajuda a consolidar nosso relacionamento técnico com esses fornecedores. Eles não querem problemas vagos. Eles querem problemas específicos que possam analisar para melhorar seus produtos.
Espero que a sugestão ajude. Eu sei que não é uma abordagem de tamanho único, mas se você conseguir, acho que valerá a pena.
A verdadeira questão é quem está no comando aqui? Se você não pode realisticamente mudar para um fornecedor alternativo, então eles têm o poder, e tudo que você pode realmente fazer é seguir o que eles dizem e esperar que funcione. Não é uma situação feliz! Caso contrário, sugiro que você peça outro representante (como os outros disseram), mas deixe claro que você não está satisfeito com o serviço e procurará em outro lugar se não puder fazer o trabalho.
Não apenas "faça os ajustes que eles sugeriram" se você tiver certeza de que eles não funcionarão, já que isso está estabelecendo um padrão para o seu relacionamento que irá prejudicá-lo a longo prazo. Você está pagando a eles para fornecer um serviço, e eles não devem ser capazes de ditar suas ações mais do que alguém que eu contratar para pintar minha casa pode ditar de que cor será.
Isso pode soar drástico, já que parece que isso não é uma questão extremamente crítica, mas o fato é que, se eles estão brincando com algo menor, provavelmente farão o mesmo por algo grande, e a última coisa que você O desejo é encontrar algum tipo de charlie foxtrot horrível seis meses depois e ter o mesmo problema com o fornecedor.
Certifique-se de que os passos que você tomar para resolver o problema agora funcionarão igualmente bem quando você estiver a dois dias de um prazo e tudo quebrar ...
Vou postar uma visão do lado do fornecedor.
Tivemos esse cliente que tinha esse problema recorrente, em que o desempenho do software caía a cada poucas horas, a uma taxa realmente péssima, e voltava algumas horas depois.
O perfilador de bulitina no sistema indicou que a velocidade do CPU do sistema (ou possivelmente memória) era repugnantemente lenta, algo como 100MHZ em vez do esperado 2GHZ. Duplicar a CPU fornecida pela VM não alterou o sintoma e eles pensaram que estávamos desperdiçando.
Como eles não conseguiam uma CPU mais rápida (mais CPUs não ajudariam), nós tentamos trocar as máquinas virtuais TEST e PROD. O problema apareceu no teste no dia seguinte. Em seguida, tentamos promover um dos clientes para uma instância autônoma (sem servidor). Nenhum problema nessa estação de trabalho enquanto o servidor estava sufocando.
Eles produziram relatórios do host da VM, indicando que não há problemas de desempenho, e tentaram novamente afirmar que se tratava de um problema de aplicativo.
Por fim, eu [um engenheiro] (eu não tive nenhum suporte daqueles em funções de suporte dedicado) pedi especificamente uma caixa física. O cliente gritou assassinato sangrento, mas sem ninguém ter qualquer outra solução potencial que eles fizeram. O que você sabe, o problema desapareceu magicamente?
Nós nunca descobrimos qual era o problema. Todos os programas de benchmark mostraram-se normais, mas o criador de perfil de aplicativos estava nos dizendo que os recursos de computação simplesmente não eram adequados. Há uma espécie de assinatura específica que procuramos no perfil agora. Se virmos isso, sabemos antes de chegarmos mais longe, o problema é a interação da VM, mas ela simplesmente não era conhecida na época.
Eles com certeza pensaram que eu estava cheio disso. Eu não estava. Eu estava sem opções.
EDIT, atualização anos depois:
Com mais e mais clientes querendo rodar em VMs e gerenciamento dispostos a tentar resolver o problema a todo custo, conseguimos um bom hardware de VM. Consegui construir um programa de gravação de VM especializado que funcionava no espaço do usuário (e não exigia privilégios) em duas VMs de núcleo único com 512 MB de RAM, que conseguiu drenar 1/3 do desempenho de memória de outra VM de núcleo único com apenas 4 total de núcleos fora de 16 em uso no host da VM e a maioria de seu RAM ainda está livre. O programa não levantou alarmes e não mostrou nada fora do comum no host da VM nem em nenhum dos convidados, exceto pelo fato de o acesso à memória ser lento.
Agora, podemos dizer aos clientes que sabemos que há um problema com as VMs e não é nosso software. Ainda recebemos solicitações de clientes de tempos em tempos para softwares compatíveis com VM. Eu me pergunto por que o gerenciamento não permite que o suporte diga a eles que somos capazes de desenvolver um software que retarda todas as outras VMs no mesmo host.
O mais assustador é que a técnica envolvida é uma transformação simples de uma técnica de programação bem conhecida, envolvendo sincronização livre de bloqueio. Centenas de fornecedores de software podem ter esse dispositivo de drenagem de VMs em seu software e não sabem disso. Conseguir um bloqueio de instruções atômicas que seriamente contestado deveria ser raro, mas não impossível. A parte divertida de tudo é que eu estava recebendo o bloqueio para contestar VMs ACROSS.
Eu sugeriria uma abordagem muito diferente das mencionadas até agora. Antes de discutir com o fornecedor, por que não analisar mais de perto o problema relatado e ver o que isso significa.
Quais são os problemas reais relatados e quais são as expectativas dos usuários? Se um usuário estiver dizendo algo "demore demais", pergunte-lhes exatamente o que "é" (para que você possa reproduzi-lo), por quanto tempo eles acham que deve ser feito e por que eles acham que deve demorar tanto tempo. Se as expectativas deles forem razoáveis, meça o desempenho real e o impacto no sistema do que eles estão tentando fazer. O fato de seu sistema mostrar um pico de 30% ao longo de um mês não significa que ele não esteja sendo executado em > 100% quando o usuário estiver tentando a consulta. Se você puder demonstrar ao seu fornecedor que a CPU e a memória não estão sendo prejudicadas pela tarefa problemática, peça ao fornecedor para justificar as recomendações que lhe custarão dinheiro.