Armadilhas da virtualização / lições aprendidas

Quais são algumas das armadilhas ou lições aprendidas após a conversão do hardware existente em um ambiente virtualizado? Existe algo que você tentou virtualizar, mas nunca fará de novo?

SEMPRE ejete qualquer mídia virtual (CD / DVD / disquete), uma vez que você tenha terminado, pois muitas vezes interromperá o vMotion em suas faixas.

Obtenha sua configuração NTP e DNS corretamente, isso evitará que você pense em suicídio :)

Você nunca pode ter memória ou armazenamento suficiente.

Verifique se você tem acesso remoto, sem sistema operacional, às suas máquinas, como o sistema iLO da HP.

Mantenha um repositório de arquivos OS / App .ISO.

Não é uma resposta direta à sua pergunta, mas na esperança de que alguém evite arrancar os cabelos no futuro ao encontrar essa resposta - os servidores blade HP não são enviados com o bit 'VT' ativado por padrão, é necessário ativar no BIOS (F9). Sem isso, o ESX 3.5U4 não gera um erro útil, apenas trava antes da instalação do código :(

Para responder à pergunta conforme solicitado - armadilhas relacionadas às migrações de P2V.

Primeiro: as migrações de P2V funcionam muito bem em sua maior parte. Quanto mais limpos e novos forem os sistemas, melhor, mas mesmo com a migração de sistemas antigos (sistemas NT4), minha taxa de sucesso após mais de cem migrações em vários ambientes tem sido de cerca de 90%. São sistemas que migraram e foram entregues à produção no dia (principalmente na noite) planejado. Eu só tive um sistema que tivemos que reverter após uma migração aparentemente bem-sucedida - uma caixa SQL que precisava de mais potência da CPU do que a plataforma poderia fornecer. O VMware Converter é bom e gratuito (para a versão não corporativa), o Platespin é muito bom (mas caro).

Dito isto - há coisas a evitar.

Clusters MSCS. Você pode fazê-los funcionar, mas nunca é uma ótima idéia e a Microsoft quase certamente não o ajudará se você tiver problemas mais tarde. Crie novos sistemas independentes.

Grandes servidores SQL - ênfase em grandes. Eles deveriam ter sido sinalizados em vermelho a partir de um POV de requisitos de CPU com antecedência, mas não se sinta tentado a mudar um se não tiver certeza de que a VM de destino terá amplo espaço para CPU.

Se você planeja alterar nomes de sistema ou endereços IP (ou ambos) durante a migração, primeiro considere não fazer isso e se você não tiver absolutamente nenhuma escolha, verifique se há pessoas à mão que entendem como essas alterações podem afetar o sistemas em questão. Minha pior migração de todos os tempos foi um servidor RSA ACE usado para autenticar uma VPN localizada na DMZ, onde o cliente se recusou a ouvir minhas objeções e insistiu em alterar o nome e o endereço IP durante a migração.

Relacionado ao acima - se você tiver algo diferente de uma rede completamente plana, crie algumas VMs de teste e garanta 100% de certeza que suas redes de VM replicam perfeitamente as físicas das quais você está migrando.

Nos ambientes Windows AD, verifique sempre se você tem uma conta de administrador local na caixa que está sendo migrada. E teste antes de migrar.

Certifique-se de ter uma boa idéia de quanto tempo as coisas levarão. Os tempos de cópia de P2V variam dependendo da largura de banda de rede disponível (obviamente), mas também podem ser afetados drasticamente pelo número de arquivos em cada volume que está sendo migrado. Isso é particularmente um problema com a migração dos sistemas NT4 * do Platespin, mas afetará qualquer cópia de software P2V no nível do arquivo (o que geralmente se aplica se você optar por redimensionar volumes). Taxas de cópia de 70-80Megabyte por segundo são possíveis com redes GigE, fonte relativamente rápida e uma boa configuração de destino, mas 20-30Megabyte / s é mais típico e para os sistemas NT acima mencionados com redes 100Meg e muitos arquivos que eu já vi taxas de cópia desça na faixa de 50kilobyte / s.

• Idealmente, você se livraria deles, mas algumas pessoas não têm esse luxo e obter um SO desse hardware completamente irreparável em que provavelmente está rodando é quase sempre uma boa idéia.

• Tenha uma sólida estratégia de backup em prática previamente. Decida se você deseja fazer backup da VM como se fosse bare metal ou se deseja fazer backup dos discos rígidos virtuais nos armazenamentos de dados (ou ambos). De um modo geral, descobri que minha pegada de backup necessária aumentou significativamente no início, portanto, esteja preparado para um pico inicial em que você poderá fazer backup de uma máquina física antiga e de uma nova VM antes de resolver todos os problemas.
• A expansão da VM também é algo a se observar. Depois que a virtualização começa a decolar, o desejo de mudar tudo para a VM se torna grande. Embora isso possa funcionar, você provavelmente não solicitou exatamente o hardware necessário imediatamente.
• Eu acho que existem máquinas que não podem ser convertidas e outras que provavelmente não deveriam ser convertidas. Embora seja bom poder pegar uma máquina física de 10 anos e cloná-la em uma VM, com warts e tudo, certamente existem cenários em que seria melhor criar um
  SO limpo e migrar objetos da máquina física. Às vezes, é melhor não converter as teias de aranha.
• Esteja preparado para usar muitas portas de rede. Se você possui sistemas que são executados em VLANs diferentes, enquanto portas únicas podem ser entroncadas, você provavelmente deseja ter portas individuais para suas VLANs alimentando seu vSwitch. Se você deseja redundância e está usando o iSCSI, pode observar várias NICs.

Pela minha experiência, tenha MUITO cuidado com o seu meio de armazenamento. Fomos com uma SAN iSCSI que acabou suportando apenas conexões de 100Mbit. A execução de uma VM no sistema não era ruim, duas eram menos adequadas ... e quando atingimos nossa meta de 8 VMs, elas eram horríveis.

Minha lição pessoal aprendida: verifique as IOPS classificadas e leia mais opiniões sobre um produto relacionado à maneira como você pretende usar o dispositivo de armazenamento

Outra coisa útil que aprendi ... Fazer uma imagem de disco de 'backup' após a instalação e o fortalecimento da base irá acelerar a construção de qualquer outro sistema e é uma coisa muito útil para se manter por perto.

Tente não executar servidores de banco de dados de produção em um ambiente virtual. As despesas gerais para E / S são inaceitáveis. Tivemos grandes problemas quando nosso DBA permitiu que nosso servidor MSSQL primário fosse virtualizado. As consultas demoravam milhares de milissegundos para serem executadas. Quando os convencemos a voltar para uma caixa dedicada, houve um aumento de 10.000% na taxa de transferência e na velocidade.

Use rede redunante para tráfego vmotion / vmkernel. Você não quer que as máquinas virtuais sejam desligadas apenas porque um switch foi reiniciado.

Ah, e deixe um servidor DC / DNS / DHCP fora da virtualização. Seus usuários o odiarão menos se você sofrer uma falha grave na SAN.

Caso você ainda não tenha uma - Faça um backup completo da máquina física antes da migração. Uma imagem provavelmente é a melhor opção e uma restauração do sistema / ASR ou qualquer outra coisa que lhe forneça um instantâneo completo do sistema, em vez do backup de conteúdo usual da maioria das máquinas.

As ferramentas P2V podem sair pela culatra inesperadamente, arruinando a máquina física (eu fiz o VMWare matar uma máquina que estava tentando fazer P2V uma vez, felizmente, era apenas uma migração de teste). Esteja preparado para ter que restaurar o sistema do zero. Sim, essa é talvez uma chance de 1000 para uma, mas você quer ser essa?

O VMWare Converter cria máquinas virtuais que são inicializadas a partir do scsi. As máquinas virtuais do MS não podem inicializar a partir do scsi. [editar - aparentemente a versão 4 do conversor agora permite que você especifique SCSI ou IDE, eu amo esses caras]

Se você deseja virtualizar uma máquina física que não seja da ACPI , compre algum software para esse fim. (a menos que você tenha algumas semanas para uma emocionante jornada de descoberta!)

Além disso, o VMWare Converter abordará trabalhos nos quais o MS SCVMM jogará as mãos em desespero.

Traga muita RAM.

Não faça nada até que as ferramentas de virtualização (VMWare ou MS) tenham sido instaladas.

Se você for movê-lo para outra plataforma / versão, desinstale as ferramentas mencionadas acima.

Cuidado com os limites da CPU. O P2V de uma CPU com 2 janelas 2000 me ensinou que apenas 1 é suportado.

• 2000 - 1 núcleo
• 2003 - 2 núcleos
• 2008 - 4 núcleos

Se você usar a SAN para armazenar suas imagens de VM, certifique-se de rotular seus dispositivos e hosts MUITO CLARAMENTE. A remoção de mapeamentos de host para disco na SAN faz coisas terríveis se eles ainda estiverem em uso pelas VMs.

A Microsoft não suporta o Exchange 2003 em execução no VMware (pelo menos essa foi a resposta oficial). Com muita torção no braço, conseguimos obter apoio não oficial deles, mas isso causou dores de cabeça extras em uma crise já estressante.

Muitos deles são específicos do VMware:

• Se tiver um desempenho ruim como uma máquina física, terá um desempenho ruim como uma máquina virtual.
• O ISO do Cold Clone é seu amigo
• Lixo dentro, lixo fora. Se você estiver usando sistemas mais antigos, eles podem deixar uma pegada desnecessária. Consulte Visualizando o hardware fantasma após o P2V , etapas necessárias após o P2V e p2v-scripts.pdf
• Verifique se seus sistemas operacionais convidados são suportados pelo seu software P2V.
• Windows 2000 pode ser um problema em relação aos drivers SCSI

Aborrecimento estúpido com o VMware: versões diferentes do VMware usam drivers SCSI diferentes para seus dispositivos de disco virtual. É perfeitamente possível perder 2 horas antes de considerar essa opção.

Bem, até agora não tenho nenhuma história de horror sobre mim mesmo fazendo a virtualização. No entanto, algumas notas embora.

1. Planejando com cuidado em detalhes adiante. Especialmente, faça alguns trabalhos de casa que não possam ser virtualizados.

2. Se o fornecedor do aplicativo em execução no servidor não suportar o ambiente virtual, aguarde até que ele seja compatível.

3. Implemente w / a SAN como o armazenamento que armazena todas as imagens da VM.

4. Execute o ESX ou ESX (i), ou Hyper-V, para obter mais desempenho.

Talvez mais, mas é tudo por agora. :)

[update] aqui está outro. Aplique o firmware mais recente ao servidor host. Eu tinha um que não fiz, o que me deu uma tela roxa uma vez por alguns dias e travou completamente o servidor.

O impacto da virtualização representa cerca de 5% do desempenho da sobrecarga. Avalie o consumo de recursos no ambiente existente para determinar se o ambiente de virtualização pode suportar essa carga.

Antes de entrar em operação com sua solução de virtualização:

• Verifique se você sabe como fazer backup e restaurar a VM. O uso do instantâneo pode não ser suportado, como no Windows DC
• Pergunte ao seu editor se sua solução é suportada dentro da VM. A Microsoft mantém uma lista dos softwares suportados na VM: KB 897613
• Como é muito fácil criar VM, as pessoas tendem a gerar uma nova VM para cada solicitação. Então você tem mais VM do que sua solução está planejada para oferecer suporte.

Existe algo que você tentou virtualizar, mas nunca fará de novo?

Eu não diria que não tentaria novamente, mas a virtualização em camadas não é agradável de lidar.

Por camadas, quero dizer executando xen ou esx em hardware virtualizado como Egenera, HP Virtual Connect ou Cisco UCS. Parece uma boa ideia, mas pode demorar muito para depurar.

No VMWare, saiba onde os instantâneos terminam. Tínhamos o nosso configurado para terminar no LUN na SAN com os próprios arquivos da VM. Um técnico estava praticando o processo Snapshot em um LUN que estava quase cheio. Mais tarde, ele reiniciou a VM por algum motivo, e os arquivos de log fizeram com que a VM não iniciasse. Foi um pouco de sorte que nos levou ao LUN como causa.

Se você optar por um VHD em expansão dinâmica, garanta que você seja grande o suficiente. Se você vai com 100 GB e acaba usando apenas 20 ... não é demais. No entanto, se você foi com 25, então você tem algum trabalho pela frente.