Ao implantar um único servidor em um novo hardware, você virtualiza ou não?

Question

Existem algumas questões que eu encontrei no ServerFault que sugerem este tópico, e embora possa ser um pouco baseado em opinião, eu acho que ele pode se encaixar nessa categoria "boa subjetiva" com base no seguinte:

Questões subjetivas construtivas:

* tend to have long, not short, answers
* have a constructive, fair, and impartial tone
* invite sharing experiences over opinions
* insist that opinion be backed up with facts and references
* are more than just mindless social fun

Então isso fora do caminho.

Estou ajudando um colega de sistema que está substituindo um servidor físico antigo que executa o Windows 2003 e ele está procurando não apenas substituir o hardware, mas "atualizar" para 2012 R2 no processo.

Em nossas discussões sobre seu hardware substituto, discutimos a possibilidade de ele instalar o ESXi e, em seguida, tornar o "servidor" 2012 uma VM e migrar os aplicativos / arquivos / funções antigos do servidor 2003 para a VM em vez de para um não -VM instalar no novo hardware.

Ele não percebe a qualquer momento nos próximos anos a necessidade de mover qualquer outra coisa para uma VM ou criar VMs adicionais, então no final isso será um novo hardware executando uma instalação normal ou um novo hardware executando uma única VM no ESXi.

Minha própria experiência ainda seria uma VM, não há uma razão realmente convincente para fazê-lo além das possibilidades que podem surgir para criar VMs adicionais. Mas há o aspecto adicional de sobrecarga e gerenciamento do hipervisor agora, embora eu tenha experimentado melhores recursos de gerenciamento e capacidade de relatório com uma VM.

Assim, com a premissa de esperar que isso permaneça na categoria "boa subjetividade" para ajudar os outros no futuro, quais experiências / fatos / referências / respostas construtivas você tem para ajudar a apoiar os resultados (virtualizando ou não)? um único "servidor")?

    

Answer 1

No caso geral, a vantagem de colocar um servidor independente em um hipervisor é à prova do futuro. Torna as expansões ou atualizações futuras muito mais fáceis, muito mais rápidas e, consequentemente, mais baratas. A principal desvantagem é a complexidade e o custo adicionais (não necessariamente financeiramente, mas a partir de uma perspectiva de homem-hora e tempo).

Então, para chegar a uma decisão, eu me faço três perguntas (e geralmente prefiro colocar o servidor em um hipervisor, pelo que vale a pena).

1. Qual é o custo adicional do hipervisor?
   • Financeiramente, é geralmente mínima ou inexistente.
     • Tanto a VMware quanto a Microsoft têm opções de licenciamento que permitem que você execute um host e um único convidado gratuitamente, e isso é suficiente para a maioria dos servidores independentes, sendo as exceções geralmente servidores que consomem muitos recursos.
   • Do ponto de vista de gerenciamento e recursos, determinar o custo pode ser um pouco mais complicado.
     • Você basicamente dobra o custo de manutenção do sistema, porque agora você tem dois sistemas para monitorar, gerenciar e manter atualizados os patches e atualizações (o sistema operacional convidado e o sistema operacional host).
       • Para a maioria dos usos, isso não é grande coisa, já que não é muito difícil manter um servidor, mas para algumas organizações especialmente pequenas ou especialmente desafiadas tecnicamente, isso pode ser uma preocupação real.
     • Você também adiciona as habilidades técnicas necessárias. Agora, em vez de precisar de alguém que possa baixar atualizações do Windows Update, você precisa de alguém que saiba o suficiente para gerenciar e manter o ambiente de virtualização.
       • Novamente, geralmente não é um problema, mas, às vezes, é mais do que uma organização pode lidar.
         
         
2. Qual é o tamanho do benefício da facilidade de atualização ou expansão?
   • Isso se resume à probabilidade de expansão futura, porque, obviamente, se eles não expandirem ou atualizarem seus ativos de servidor, esse benefício será zero.
     • Se esse é o tipo de organização que vai encher o servidor em um canto e esquecê-lo por 10 anos até que precise ser substituído de qualquer maneira, não faz sentido.
     • Se eles provavelmente crescerem organizacionalmente, ou mesmo tecnicamente (adicionando novos servidores com funções diferentes, em vez de apenas ter um servidor all-in-one), isso proporciona um benefício bastante substancial.
       
       
3. Qual é o benefício agora ?
   • A virtualização traz benefícios além da proteção do futuro e, em alguns casos de uso, eles podem ser substanciais.
     • O mais óbvio é a capacidade de criar instantâneos e backups triviais para restaurar antes de fazer algo no sistema, por isso, se ficar ruim, você poderá reverter com um clique.
     • A capacidade de experimentar com outras VMs (e jogar o jogo "e se") é outra em que eu já vi a gerência ficar animada. Para meu dinheiro, porém, o maior benefício é a portabilidade adicional que você obtém ao executar um servidor de produção em um hypervisor. Se algo sair realmente errado e você entrar em uma situação de recuperação de desastres ou de restauração de backups, será quase infinitamente mais fácil restaurar uma imagem de disco em uma máquina que esteja executando o mesmo hipervisor do que tentar fazer uma restauração bare-metal. / li>

Answer 2

Acho que o sistema operacional virtualizado é um grande fator, juntamente com os requisitos de desempenho e o potencial de expansão / crescimento. Os servidores atuais costumam ser excessivamente poderosos para os aplicativos e sistemas operacionais que usamos. Na minha experiência, a maioria dos sistemas Windows padrão não pode fazer uso eficiente dos recursos disponíveis em um servidor dual-socket moderno . Com o Linux, aproveitei algumas das ferramentas granulares de gerenciamento de recursos ( cgroups ) e contêineres ( LXC ) para fazer um melhor uso dos sistemas físicos. Mas o mercado é definitivamente voltado para o hardware otimizado para virtualização.

Dito isso, eu virtualizei sistemas únicos em vez de instalações bare-metal em algumas situações. Motivos comuns são:

• Licenciamento - O número cada vez menor de aplicativos que licenciam com base em limites rígidos de núcleo, soquete ou memória ( sem considerar as tendências da computação moderna ). Veja: Desativar núcleos de CPU no BIOS?

• Portabilidade - A virtualização de um servidor abstrai a VM do hardware. Isso torna as alterações de plataforma menos prejudiciais e permite que a VM faça referência a dispositivos / componentes virtualizados padrão. Consegui manter sistemas decrépitos ( mas críticos ) do Windows 2000 na vida -suporte usando esta abordagem.

• Expansão futura - Tenho agora um cliente com um controlador de domínio do Windows 2003 em execução no hardware de 2001. Estou construindo um novo sistema ESXi de host único para eles, que abrigará um novo controlador de domínio 2012 R2 para o interino. Mas mais VMs seguirão. Nesta configuração, posso oferecer uma expansão de recursos confiável sem custos adicionais de hardware.

As desvantagens de fazer isso com um único host / VM única é o gerenciamento. Eu estou vindo da perspectiva da VMware, mas no passado, o ESXi era um pouco mais amigável com esse arranjo. Atualmente, o requisito do vSphere Web Client e do acesso restrito aos recursos básicos torna a execução de um único host ( e single-VM ) menos atraente.

Outras considerações são o monitoramento de hardware prejudicado e mais complexidade envolvida com periféricos externos comuns (dispositivos USB / unidade de fita / backups / Soluções UPS ). Os hipervisores de hoje realmente querem fazer parte de um conjunto maior de gerenciamento.

    

Answer 3

Existem alguns benefícios na virtualização de um único servidor. As primeiras coisas que vêm à mente são

• Criar instantâneos
• Importar / exportar VMs (por exemplo, exporte a VM como um .OVF para que os desenvolvedores possam carregá-la na estação de trabalho ou no player para ter uma cópia exata de um servidor)
• Clone facilmente ou crie um modelo (para quando você decide que as VMs são legais)
• Facilmente disponível para adicionar outras VMs no futuro

Acho que o mais importante deles seria a capacidade de captura instantânea. Usamos o VMWare em toda a empresa, então, para nós, faria sentido ter o servidor "pronto" para quando houver necessidade de mais VMs.

    

Answer 4

Esta não é uma resposta longa, mas de qualquer forma:

A razão mais convincente para usar um hipervisor para um único servidor, especialmente com algo como o Windows Server, é que você tem total abstração de hardware para o sistema operacional de produção e pode simplesmente movê-lo para um novo hardware de servidor sem nenhum problema. surgir. Considero isso um recurso valioso que supera de longe as desvantagens de ter um hipervisor prático desnecessário sendo executado em segundo plano.

    

Answer 5

Eu não vou fornecer uma resposta tão detalhada aqui quanto os outros, então eu vou apenas dizer que eu estou encontrando cada vez mais difícil justificar a instalação do sistema operacional do servidor em bare-metal em vez de instalar um hypervisor (de sua escolha) e virtualizar as cargas de trabalho. As vantagens de fazer isso, na minha opinião, são:

1. Benefício de custo. No longo prazo, se precisar implantar cargas de trabalho adicionais, não precisarei desembolsar mais hardware para essas cargas de trabalho adicionais. Em alguns casos, ao usar o Hyper-V, posso até economizar em meus custos de licenciamento.

2. Facilidade de implantação e reimplementação.

3. Facilidade de implementar alta disponibilidade e failover.

4. Portabilidade. Eu provavelmente posso mover a VM praticamente em qualquer lugar se eu precisar descomissionar ou terceirizar o host atual.

5. Revisão futura. Seu colega de sistema talvez não veja nenhuma necessidade futura de uma infraestrutura baseada em hipervisor, mas meu palpite é que dentro de 12 a 24 meses ele irá e ficará feliz por ter optado pela rota de virtualização, se de fato escolher essa rota .

6. Recuperação de desastre. Eu posso fazer backup de uma VM inteira e restaurá-la ou replicá-la para outro host em questão de minutos.

E assim por diante e assim por diante ...

    

Answer 6

Aqui estão algumas razões pelas quais eu diria que uma VM é melhor:

• Built-in "KVM sobre IP" (mais ou menos) - você pode acessar seu servidor remotamente no console sem precisar de um KVM sobre IP. Às vezes você não quer fazer algo sobre o RDP e precisa de acesso ao console. Com uma VM, você ativa a ferramenta de gerenciamento de escolha (XenCenter, vSphere Client, etc) e está no console da sua VM.

• Com VMs (e para servidores não VM, com meu KVM sobre IP) não preciso mais ficar na minha sala de servidores frios por horas.

• Migração para novo hardware - com a atualização do SO à parte, para instalar o novo hardware, é preciso migrar o sistema, mudar as coisas, etc. Com uma VM, você (geralmente) não precisa fazer nada. Você atualiza seu hardware, coloca os arquivos da VM no novo hardware e ativa.

• Enquanto um não prevê a VM futura, " se você construir, eles virão ". Você vai querer criar uma nova VM para testar algo e experimentar coisas novas, etc. Há muito mais possibilidades.

• As VMs oferecem a capacidade de reverter com o instantâneo, fazer uma cópia dele, criar um clone da VM (em tempo de execução) e ativá-lo - seja para testar algo antes de colocá-lo ao vivo ou apenas ter um segundo do primeiro. Há muitas coisas que você pode fazer com os instantâneos de VM e os gostos.

• Redundância - se você lançar um segundo servidor VM, pode ter hardware redundante e, embora eu não saiba sobre os atuais esquemas de licenciamento VMWare, o XenServer agora tem o XenMotion aparentemente como parte do pacote gratuito. pode não se aplicar.

Os motivos pelos quais eu não usaria uma VM:

• Sobrecarga - dificilmente, mas obviamente há alguma sobrecarga.

• Mais complexo para gerenciar - um pouco mais complexo, mas é fácil de aprender. Se você não está indo para um ambiente virtualizado maciçamente grande, o treinamento é trivial.

Answer 7

Estou chegando atrasado e sinto que as pessoas já fizeram alguns dos pontos que eu gostaria de fazer, mas vou recapitular brevemente:

• À prova de futuro: Mais fácil de adicionar mais RAM / CPU / disco / etc. conforme a necessidade surgir.
• Portabilidade: mais fácil migrar para um novo hardware, especialmente em caso de desastre.
• A virtualização é melhor do que manter um hardware antigo e horrível para rodar algo que você não consegue se livrar.
• O software de gerenciamento geralmente é tão bom quanto o KVM ou o DRAC. (Além disso, se você herdar algo do qual o administrador anterior partiu sem deixar sua senha, você pode usá-los como "acesso físico" para invadir. Tão prático quanto os cortadores de parafuso que tenho no meu carro pelo mesmo motivo - anterior admin em um trabalho usava cadeados no hardware. Eu herdei os servidores, mas não a chave.
• Capturando instantâneos e fazendo cópias para que eu possa testar procedimentos arriscados antes de implantá-los.

No entanto, o que ninguém mencionou ainda e provavelmente deve ser mencionado: Se você está no tipo de loja onde as pessoas podem precisar de um servidor de teste, e provavelmente vão resolver essa necessidade pegando um desktop sobressalente e dando tapas Em um sistema operacional de servidor, ser capaz de oferecer uma VM provavelmente servirá melhor às suas necessidades. A virtualização do novo servidor pode ser a "razão" para permitir futuras expansões virtuais. (E, francamente, se você não está nesse tipo de loja, provavelmente já tem virtualização.)

Claro, nem tudo virtualiza. Eu marquei o hardware físico para o software de gerenciamento que incluía o PXE, descrevendo a eles o que eles precisariam fazer para desativar o descarregamento do segmento TCP ( O PXE funcionava como um cão de uma perna só com o TSO , mas eles precisavam desativá-lo para toda a VLAN virtual, e não estavam inclinados a fazer isso. Então, se o novo servidor é algo especializado o suficiente para ser inadequado, bem, não importa.

Mas, salvo esse tipo de especialização, valeria a pena se livrar de um monte de máquinas de classe de PC (potencialmente não gerenciadas) que executam sistemas operacionais de servidor por aí, agora ou no futuro.

    

Answer 8

Absolutamente, virtualizo sempre que posso. Isso permite que eu me prepare para fazer o seguinte no futuro:

• Backups completos do sistema que são muito mais fáceis de fazer e, muitas vezes, mais baratos também.
• O sistema operacional pode ser portátil, posso mover a VM para outro host se precisar, com ou sem tempo de inatividade e armazenamento em cluster, não importa neste momento
• O licenciamento do Windows pode se tornar mais barato sob certas condições
• Quando estou com pouco hardware, posso usar sistemas de produção para testar atualizações (não a prática recomendada, mas o orçamento, o orçamento ...), depois de tirar uma foto. Não é possível fazer isso em um host comum, a menos que esteja inicializando de uma SAN cara
• Obtendo o hardware de servidor final mais baixo possível, ainda recebo mais recursos do que o necessário para uma função de servidor específica. Pode também obter um hardware melhor e usar tudo isso com VMs.
• Os recursos de virtualização geralmente podem substituir softwares desnecessários. Por exemplo, eu costumava configurar o doubletake e nunca falhava muito, para configurar réplicas de DR de servidores Windows. Com a virtualização, posso fazer isso no nível do hipervisor, utilizando tecnologias muito mais baratas e executando soluções mais confiáveis e flexíveis.

Em resumo, a menos que o servidor execute um software específico com limitações, proibindo que ele seja virtualizado (requisitos de latência estrita de IO de rede ou disco geralmente, e com o hardware correto, mesmo aqueles que podem ser obtidos com virtualização) para manter as coisas o mais virtuais possível.

    

Answer 9

Uma razão pela qual posso pensar a favor da virtualização de um único servidor em uma VM em um único host é a capacidade que ele oferece para, então, mexer em um ambiente de teste para esse "servidor".

Se o hardware é mais do que capaz, você pode clonar a VM do servidor e remover suas capacidades de NIC / rede e isolar o clone como uma "plataforma de teste" para mexer antes de tentar o mesmo no servidor de "produção". Um exemplo seria se o servidor estiver executando um software ERP e você quiser testar o que aconteceria se você executasse um script específico em relação ao software / banco de dados do ERP. Você poderia fazer isso na VM clonada como um teste primeiro. Isso pode ser feito em conjunto com um instantâneo da VM ativa antes da implantação, com o benefício adicional de saber que ela deve funcionar bem.

Criar o mesmo ambiente de "teste" clonado poderia ser feito com um P2V de um servidor físico existente, mas você precisaria de um host físico adicional para colocar sua nova VM de teste em ... acima, tudo pode residir em o mesmo hardware físico (que hoje em dia é quase sempre um exagero para uma única VM)

    

Answer 10

Se o seu caso de uso não exigir 100% da energia do hardware dedicado, eu ficaria virtual todas as vezes. Ele oferece flexibilidade, recursos de snapshot e acesso embutido ao console (mesmo que você também deva usar gerenciamento fora de banda)

    

Answer 11

Um único ponto que é bastante tangencial à questão principal:

Eu recentemente tive uma VM cujo disco não era grande o suficiente. Ele estava executando algo que gerava grandes quantidades de dados em um banco de dados relacional, que por motivos de desempenho tinha que estar na mesma máquina.

Após expandir a imagem do disco duas vezes, cheguei ao estágio em que não havia espaço suficiente no host para copiar e expandir a imagem com segurança novamente. Eu teria me poupado alguns dias de trabalho para ter feito isso desde o início em uma máquina dedicada, mesmo que fosse um PC barato, não um servidor de alto desempenho.

Com uma máquina dedicada, você pode simplesmente desligá-la e adicionar mais discos. Se for um servidor que executa outras VMs, a menos que você tenha compartimentos extras de hot swap, você pode ter um problema para desativá-lo.