Quando NÃO usar a virtualização?

Question

Quando a virtualização era nova, tentamos virtualizar tudo, mas notamos casos de uso em que nossas máquinas virtuais eram muito mais lentas que um bare metal.

Para nós, usamos as seguintes regras ao decidir não virtualizar:

• Aplicativos de rede intensiva de E / S (ou seja, com muitas interrupções / pacotes)
• Aplicativos intensivos de disco IO (se não em armazenamento SAN)
• RAM intensivo (este é o recurso mais precioso)

Nós tivemos essas experiências com Xen e DRDB, assim como o DAS-nada do Hyper-V com o DAS. Este é o caso de todos os hipervisores?

Quais (outras) métricas eu devo procurar ao decidir virtualizar um aplicativo / servidor ou não?

    

Answer 1

Você atingiu as principais métricas da sua pergunta:

• Rede IO
  Você quer ter certeza de que sua carga de trabalho de virtualização proposta não irá saturar a conexão de rede do seu sistema host. Nesses dias de placas de rede de 10 Gbit, isso é um problema menor para empresas maiores, e as empresas menores geralmente conseguem o desempenho de que precisam a partir de NICs gigabit (ou agregados / agregados gigabit).

• Disco IO
  Você quer ter certeza de que seu subsistema de disco (discos locais, SAN, NAS) pode manipular a E / S de disco que você está propondo.
  Ao dimensionar isso, lembre-se de que sua estrutura de SAN (switches, etc.) precisa ser capaz de lidar com a carga também - você pode ter um sistema de armazenamento über-SAN que pode empurrar terabits por segundo para seus discos, mas se esse monstro está conectado a um tecido iSCSI de 100Mbit que você saturará sua rede antes que o dispositivo de armazenamento sue um pouco.

• RAM
  Mais especificamente RAM "ativa" (porque o material inativo pode ser trocado pelo hipervisor e ninguém notará). O ideal é que você tenha RAM física suficiente para o hipervisor não precisar trocar. Na realidade, você provavelmente encontrará um meio feliz de supercomprometimento.

Alguns outros a considerar:

• CPU (e padrões de carga de trabalho)
  Se você tem um monte de sistemas que fazem tarefas intensivas de CPU, você pode ter problemas se todos eles estiverem clamando pelo processador do sistema host ao mesmo tempo. (por exemplo, se você tiver 1 CPU do host e 3 VMs que querem processar números à meia-noite, cada VM verá apenas 1/3 do desempenho da CPU do host, já que o hipervisor tenta dividir o recurso contestado entre elas). br> O outro lado disso é se você tem um monte de sistemas que fazem tarefas intensivas de CPU em momentos diferentes (por exemplo, meia-noite, 3h e 6h, e sempre terminando antes do próximo cara começar) você pode virtualizá-los e nunca sabe a diferença.

• Hardware personalizado
  Alguns hypervisors (como o VMWare) permitem PCI e Storage Pass-Thru. Outros não podem.
  Se você precisar de acesso ao hardware no host (como uma placa de vídeo ou acesso direto ao disco), será necessário incluir isso no planejamento de sua virtualização.

• Marcação horária
  Os hipervisores ficaram melhores nisso, mas as tarefas de precisão de cronometragem ainda são mais adequadas para servidores físicos dedicados. O servidor NTP primário da sua organização, por exemplo, deve ser um host físico (ou um roteador, se os roteadores forem capazes de atuar como servidores NTP).

• Coisas que geralmente não virtualizam bem
  Há muitos dados sobre isso, então faça uma pequena pesquisa antes de virtualizar algo.
  Como alguns exemplos, os problemas de tempo que eu mencionei acima, sistemas VOIP (como um PBX Asterisk) e bancos de dados muito usados são geralmente maus candidatos para virtualização (os dois primeiros devido aos problemas de precisão do horário, os bancos de dados geralmente porque eles causam, e sofrem de contenção de recursos mais do que outras cargas de trabalho). Cada empresa acumula uma lista local de coisas que eles sabem que não podem virtualizar - como você encontra seus itens, certifique-se de documentá-los (incluindo o motivo, no caso de um dia você obter um hipervisor que resolva o problema).

Answer 2

Como foi apontado nos comentários, nem todos os softwares de virtualização são iguais.

link

What is the performance overhead? Near zero. There is no emulation layer, only security isolation, and all checking is done on the kernel level without context switching.

What are performance expectations? Peak performance is achieved when only one container has active tasks. In this case, it could use 100% of available resources: all CPUs, all physical memory, all disk and network bandwidth. OpenVZ is not limiting you to a single-CPU virtual machine.

Embora isso possa parecer uma falta de resposta: não há condições gerais em que você não deva usar a virtualização. Agora tenho o hábito de implantar hardware com apenas 1 contêiner OpenVZ: eles são fáceis de migrar usando as ferramentas fornecidas devido à abstração de hardware que a virtualização fornece inerentemente. Como um pequeno efeito colateral, os custos de licença de software geralmente também são mais baratos.