Como migrar um servidor criptografado superdimensionado no ESXi

5

Então, eu me meti em uma situação particular e vi algumas maneiras de resolver o meu problema, mas estou perdendo algumas partes no meio.

A base do meu problema é que eu tenho um antigo servidor gerenciado ESXi com algumas VMs debian críticas e um novo servidor ESXi que quero hospedar essas VMs. Os servidores estão em data centers separados e, embora o tamanho real das VMs seja de apenas alguns Gbs, eles são configurados como LVMs criptografados, de modo que o ESXi os considera como unidades de 3 TB totalmente preenchidas. Idealmente, gostaria de criar uma cópia das partes não críticas dessas VMs e, em algum momento, anunciar o tempo de inatividade e congelá-las e transferir as partes críticas. Se o disco não fosse criptografado, eu poderia apenas reduzir as unidades, mas, no meu entender, para diminuí-las, eu precisaria desligar os servidores, o que é menos do que ideal. Como tal, os caminhos que vejo eu poderia tomar.

  1. Transferir manualmente cada arquivo VMDK de 3 TB (extremamente lento)
  2. Tem tempo de inatividade e redimensiona para tornar a transferência mais agradável (o tempo de inatividade não é ideal)
  3. Use alguma combinação de DD, sfdisk, ferramentas LVM e dump para transferir o material para novas VMs

Eu adoraria usar 3, mas honestamente não tenho certeza exatamente como eu faria isso ou a melhor maneira de fazer isso, o que preservaria os LVMs e a configuração criptografada.

    
por Whinis 03.12.2017 / 03:52

3 respostas

1

Então, este foi o melhor cenário depois que o P2V falhou.

  1. Faça uma cópia da VM no destino com a criptografia de trabalho LVM.
  2. Crie uma segunda VM e monte o LVM criptografado para / mnt

    Important so that the server itself is not running
    
  3. Copiar chaves entre servidores para usuários raiz para evitar problemas de acesso
  4. Execute o seguinte comando

    rsync -aHxvK --numeric-ids --progress --exclude=/etc/fstab --exclude=/etc/crypttab --exclude=/etc/initramfs-tools/conf.d/* --exclude=/etc/network/* --exclude=/mnt/* --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/boot/* --exclude=/root/*   [email protected]:/* /mnt/
    

Isso copiará a maioria dos arquivos que não foram alterados e fornecerá uma "cópia" funcional do servidor. A maior parte deste rsync é mostrada em alguns guias on-line, mas descobri que o / etc / crypttab é necessário para volumes criptografados ou não inicializa e o initramfs é necessário ou você consola o spam na inicialização

Depois disso, agende um curto período de inatividade e encerre os principais serviços, como banco de dados e servidores da Web, e faça uma transferência final desses diretórios antes de criar e transferir os pontos de extremidade para o novo servidor.

    
por 12.12.2017 / 13:40
3

Devido à criptografia, não é possível realizar a migração da parte "útil" do disco apenas com ferramentas que analisam a VM do "fora". Isso inclui o vMotion, o Veeam B & R e outros.

A única coisa que me vem à mente é a migração realizada com o conversor VMware gratuito: isso permite que você execute uma migração ao vivo "P2V" olhando para a VM a partir do "interior".

Instale-o em uma VM do Windows que possa alcançar a VM e o host ESXi, selecione migrar uma máquina linux "ligada" e forneça as credenciais raiz do host VM e do ESXi. Ele fará o login na máquina e executará a migração a partir do "interior", visto que os discos estão com alguns GB cheios e transferindo apenas estes. Eu suspeito que, se você selecionar "infraestrutura", o conversor tentará tirar proveito do fato de que a VM já está na infraestrutura, e isso é ruim no seu caso específico.

Nunca tentei isso em casa nem em produção com um disco criptografado, mas realizei uma migração ao vivo de P2V com disco de 1TB de um host físico para um host ESXi, e a migração via 1GBe levou apenas cerca de 40m, enquanto o tempo bruto estimado para transferir um total de 1 TB de dados por um link GB é de cerca de 3 horas, por isso executou algo como uma cópia do tipo arquivo por arquivo.

    
por 03.12.2017 / 14:29
0

Uma solução possível:

Crie uma nova VM vazia no host de destino.

Crie ou reutilize uma VM auxiliar simples.

Conecte os discos da VM de destino à VM auxiliar, crie partições e sistemas de arquivos neles e monte-os. Se uma versão antiga (0.xx) do grub for usada, use -I 128 ao criar seus sistemas de arquivos!

Na VM auxiliar, copie o máximo possível do sistema em execução (exclua / proc e / sys !!) via rsync nos sistemas de arquivos da VM de destino. Você pode precisar de --numeric-ids, -H e --sparse / - inplace. Use --delete pensativamente.

Sempre que puder pagar, desligue o sistema de origem por um curto período de inatividade (desligue o máximo de serviços possível, esp. servidores de banco de dados!) e faça um rsync final.

Chroot na cópia. Corrija os pontos de montagem / proc e / sys, / dev (o MAKEDEV genérico normalmente fornecerá um conjunto sensato, independente do udev) eo gerenciador de inicialização (mais fácil de fazer uma instalação simples - onde os arquivos do seu dispositivo apontam! - e mais tarde use as opções manuais na primeira inicialização, depois corrija-a corretamente dentro do sistema em execução).

Não sincronize, desmonte e desconecte os discos. Inicialize a cópia (rede desconectada no início. Você provavelmente terá que ajustar as opções do gerenciador de inicialização manualmente).

    
por 12.12.2017 / 14:11