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

Existem algumas perguntas que encontrei no ServerFault que sugerem esse tópico e, embora possa ser um pouco baseado em opiniões, 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 administrador de sistemas que está substituindo um servidor físico mais antigo executando o Windows 2003 e ele quer substituir não apenas o hardware, mas também "atualizar" o 2012 R2 no processo.

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

Nos próximos anos, ele não percebe a necessidade de mudar qualquer outra coisa para uma VM ou criar VMs adicionais; portanto, no final, será um novo hardware executando uma instalação normal ou um hardware executando uma única VM no ESXi.

Minha própria experiência se inclinaria para uma VM ainda, não há um motivo realmente convincente para fazê-lo além das possibilidades que possam surgir para criar VMs adicionais. Mas agora há o aspecto adicional de sobrecarga e gerenciamento do hypervisor, embora eu tenha experimentado melhores recursos de gerenciamento e relatórios com uma VM.

Portanto, com a premissa de esperar que isso possa permanecer na categoria "bom subjetivo" para ajudar outras pessoas no futuro, que experiências / fatos / referências / respostas construtivas você tem para ajudar a apoiar qualquer resultado (virtualizando ou não um único "servidor") ?

No caso geral, a vantagem de colocar um servidor independente em um hipervisor é à prova de futuro. Torna futuras expansões ou atualizações muito mais fáceis, muito mais rápidas e, como resultado, mais baratas. A principal desvantagem é complexidade e custo adicionais (não necessariamente financeiramente, mas do ponto de vista de horas e horas).

Portanto, para tomar 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 hypervisor?
   • Financeiramente, é geralmente mínimo ou inexistente.
     • Tanto a VMware quanto a Microsoft têm opções de licenciamento que permitem executar um host e um único convidado gratuitamente, e isso é suficiente para a maioria dos servidores autônomos, com exceções geralmente sendo 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 com patches e atualizações (o SO convidado e o SO host).
       • Para a maioria dos usos, isso não é grande coisa, pois não é muito difícil manter um servidor, embora para algumas organizações especialmente pequenas ou especialmente tecnicamente desafiadas, isso possa ser uma preocupação real.
     • Você também adiciona as habilidades técnicas necessárias. Agora, em vez de precisar apenas de alguém que possa baixar atualizações do Windows Update, você precisa de alguém que conheça 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 expandem ou atualizam seus ativos de servidor, esse benefício é zero.
     • Se esse é o tipo de organização que apenas coloca o servidor em um canto e o esquece por 10 anos até que seja necessário substituí-lo de qualquer maneira, não faz sentido.
     • Se é provável que eles cresçam organizacionalmente ou apenas tecnicamente (por exemplo, adicionando novos servidores com funções diferentes, em vez de apenas ter um servidor tudo em um), isso oferece um benefício bastante substancial.
       
       
3. Qual é o benefício agora ?
   • A virtualização traz benefícios além da prova de 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 executar algo no sistema; portanto, se tudo der errado, você pode reverter com um clique.
     • A capacidade de experimentar outras VMs (e jogar o jogo "e se") é outra que eu já vi a gerência entusiasmada. 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 hipervisor. Se algo der realmente errado e você se deparar com uma situação de recuperação de desastre ou restauração de backups, é quase infinitamente mais fácil restaurar uma imagem de disco em uma máquina executando o mesmo hipervisor do que tentar fazer uma restauração bare-metal.

Eu acho que o sistema operacional que está sendo virtualizado é um grande fator, juntamente com os requisitos de desempenho e o potencial de expansão / crescimento. Os servidores de hoje 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 de soquete duplo moderno . Com o Linux, aproveitei algumas das ferramentas granulares de gerenciamento de recursos ( cgroups ) e containers ( LXC ) para fazer melhor uso dos sistemas físicos. Mas o mercado é definitivamente voltado para o hardware otimizado para virtualização.

Dito isso, virtualizei sistemas únicos em vez de instalações bare-metal em algumas situações. Os 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 levar em consideração as tendências da computação moderna ). Consulte: Desativar núcleos de CPU na BIOS?

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

• Expansão futura - Agora tenho um cliente que possui um controlador de domínio do Windows 2003 em execução no hardware da era de 2001. Estou criando um novo sistema ESXi de host único para eles, que abrigará um novo controlador de domínio 2012 R2 para o período. Mas mais VMs se seguirão. Nesta configuração, eu posso oferecer expansão confiável de recursos sem custos adicionais de hardware.

As desvantagens de fazer isso com um único host / única VM são o gerenciamento. Estou vindo da perspectiva da VMware, mas, no passado, o ESXi era um pouco mais amigável com esse arranjo. Hoje, a exigência do vSphere Web Client e o acesso restrito aos recursos básicos tornam a execução de uma solução de host único ( e VM única ) menos atraente.

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

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 arquivo .OVF para que os desenvolvedores possam carregá-la na estação de trabalho ou no Player para obter uma cópia exata de um servidor)
• Clone ou transforme facilmente em um modelo (para quando você decidir que as VMs são boas)
• Prontamente disponível para adicionar VMs adicionais no futuro

Eu acho que o mais importante desses seria os recursos de instantâneo. Usamos o VMWare em toda a empresa, portanto, para nós, faria sentido ter o servidor "pronto" para quando houver necessidade de mais VMs.

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

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

Não vou fornecer uma resposta tão detalhada aqui como outras pessoas têm, por isso vou dizer que estou achando cada vez mais difícil hoje em dia justificar a instalação do sistema operacional do servidor no bare metal, em vez de instalar um hipervisor (do seu opção) e virtualizar as cargas de trabalho. As vantagens de fazer isso, na minha opinião, são:

1. Custo benefício. A longo prazo, se eu precisar implantar cargas de trabalho adicionais, não preciso usar mais hardware para essas cargas de trabalho adicionais. Em alguns casos, ao usar o Hyper-V, posso até economizar nos meus custos de licenciamento.

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

3. Facilidade de implementar alta disponibilidade e failover.

4. Portabilidade. Provavelmente, posso mover a VM em qualquer lugar, se precisar desativar ou terceirizar o host atual.

5. Prova de futuro. Atualmente, seu administrador de sistemas talvez não veja nenhuma necessidade futura de uma infraestrutura baseada em hipervisor, mas meu palpite é que dentro de 12 a 24 meses ele o fará e ficará feliz por ter escolhido seguir a rota de virtualização, se ele realmente escolher essa rota. .

6. Recuperação de desastres. 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 ...

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

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

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

• Migração para o novo hardware - atualização do sistema operacional de lado, para instalar seu novo hardware, você precisa migrar o sistema, movimentar 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 inicia.

• Enquanto não se prevê uma VM futura, " se você a construir, elas virão ". Você deseja 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 depois aumentá-lo - seja para testar algo antes de colocá-lo no ar ou apenas para ter um segundo do primeiro. Há muitas coisas que você pode fazer com os instantâneos da VM e coisas do tipo.

• Redundância - se você instalar um segundo servidor de VM, poderá ter hardware redundante e, embora eu não conheça os esquemas de licenciamento atuais do VMWare, o XenServer agora tem o XenMotion aparentemente como parte do pacote gratuito, para que o custo adicional não seja aplicável.

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

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

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

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

• Prova de futuro: Mais fácil adicionar mais RAM / CPU / disco / etc. conforme a necessidade.
• Portabilidade: é mais fácil mudar para um novo hardware, especialmente em caso de desastre.
• A virtualização é melhor do que manter um hardware antigo horrível por perto para executar algo que você não pode se livrar.
• O software de gerenciamento geralmente é tão bom quanto KVM ou DRAC. (Além disso, se você herdar algo de onde o administrador anterior partiu sem deixar a senha deles, poderá usá-los como "acesso físico" para invadir. Tão útil quanto os alicates que eu tenho no meu carro pela mesma razão - anterior admin em um trabalho usava cadeados no hardware. Herdei os servidores, mas não a chave.)
• Instantâneos e 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 em que as pessoas podem precisar de um servidor de teste e é provável que resolva essa necessidade pegando uma área de trabalho sobressalente e dando um tapa no sistema operacional do servidor nele, poder oferecer a eles uma VM provavelmente atenderá às suas necessidades e às suas necessidades muito melhor. A virtualização do novo servidor pode ser o "motivo" para permitir futura expansão virtual. (E, francamente, se você não está nesse tipo de loja, provavelmente já possui virtualização.)

Obviamente, nem tudo virtualiza. Marquei hardware físico para o software de gerenciamento que incluía o PXE, descrevendo a eles o que eles precisariam fazer para desativar o TCP Segment Offloading (o PXE funcionava como um cão de uma perna com o TSO ativado , mas eles precisavam desativá-lo) para toda a VLAN virtual e eles não estavam dispostos a fazer isso). Portanto, se o novo servidor for algo especializado o suficiente para ser inadequado, bem, não importa.

Mas, exceto nesse tipo de especialização, valeria a pena me livrar de um monte de máquinas da classe PC (potencialmente não gerenciadas) executando sistemas operacionais de servidor por aí, agora ou no futuro.

Absolutamente, eu 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, geralmente, 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 clustering, não importa nesse momento
• O licenciamento do Windows pode ficar mais barato sob certas condições
• Com pouco hardware, posso usar os sistemas de produção para testar atualizações (não a melhor prática, mas orçamento, orçamento ...), depois de tirar uma captura instantânea. Não é possível fazer isso em um host comum, a menos que seja inicializado a partir de uma SAN cara
• Obtendo o hardware de servidor final mais baixo possível, ainda recebo mais recursos do que seria necessário para uma função de servidor específica. É melhor obter um hardware melhor e usá-lo com VMs.
• Os recursos de virtualização geralmente podem substituir softwares desnecessários. Por exemplo, eu costumava configurar o double -etake e nunca falhava muito, para configurar réplicas de DR dos 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 suma, a menos que o servidor esteja executando um software específico que tenha limitações, proibindo sua virtualização (geralmente é necessário um rígido controle de latência de E / S de rede ou de disco e com o hardware certo, mesmo os possíveis com a virtualização), tento manter as coisas o mais virtual possível.

Um motivo pelo qual posso pensar em virtualizar um único servidor em uma VM em um único host é a capacidade que ele oferece para mexer com um ambiente de teste para esse "servidor".

Se o hardware tiver mais capacidade, você poderá clonar a VM do servidor e remover suas habilidades de NIC / rede e isolar esse 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ê desejar testar o que aconteceria se você executasse um script específico no software / banco de dados ERP. Você poderia fazer isso na VM clonada como um teste primeiro. Isso pode ser feito em conjunto com um instantâneo da VM ao vivo antes da implantação, com o benefício adicional de saber que ela deve funcionar bem.

A criação do mesmo ambiente de "teste" clonado pode ser feita com um P2V de um servidor físico existente, mas você precisará de um host físico adicional para colocar sua nova VM de teste ... ... acima, tudo pode residir no mesmo físico hardware (que hoje em dia quase sempre é um exagero para uma única VM)

Se o seu caso de uso não exigir 100% da energia de hardware dedicado, eu virtualizaria toda vez. Ele fornece flexibilidade, facilidade de captura instantânea e acesso integrado ao console (mesmo que você também deva usar o gerenciamento fora de banda)

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

Recentemente, eu tinha 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.

Depois de 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 fazer 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 executando outras VMs, a menos que você possua compartimentos de hot swap, você poderá ter um problema para desativá-lo.