Como devo copiar meus modelos de VM entre os datacenters do vSphere?

Arquitetura de fundo / ambiente:

Meu ambiente atual $corp_overlords$é configurado em um modelo de hub-and-spoke com um hub de escritório doméstico tecnologicamente bem dotado (SAN, cluster ESXi de bladecenter / bladesystem, conexão de Internet por fibra etc.) conectado a vários spokes de sites remotos não muito bem e normalmente contêm um único servidor host ESXi e se conectam ao hub do escritório doméstico por meio de um T1. Todo o tráfego originado em qualquer site remoto é direcionado de volta ao escritório em casa através de uma "rede MPLS" (que é realmente apenas um T1 conectando o site remoto ao escritório em casa).

No escritório em casa, na SAN, temos vários modelos de VM que eu criei para implantar VMs. Eles são armazenados em um volume NFS, que é um armazenamento de dados do vSphere, anexado ao objeto de datacenter do escritório em casa no vSphere.

Cada site remoto tem um objeto de datacenter do vSphere correspondente, contendo um objeto de armazenamento de dados conectado ao armazenamento conectado localmente no servidor host ESXi localizado fisicamente no site remoto.

Como esses modelos de VM existem no volume NFS, eles ocupam ~ 40 GiB (thin-provisioning). Como arquivos no NTFS (ou no Linux FS), eles ocupam ~ 100 GiB.

Questão:

Como devo copiar esses 40 GiB de dados thin-provisioned (que ocupam 100 GiB de espaço no sistema de arquivos) entre meus sites?

Estou sob as restrições de que tenho aproximadamente 5 dias para fazer isso e não posso interferir (notavelmente) no "tráfego de rede normal".

Que tal usar o ovftool para copiar os modelos diretamente entre hosts?

Eu já usei isso para VMs antes e funciona muito bem. Não tenho certeza se isso também funciona para modelos, mas, se não, você pode apenas esconder temporariamente os modelos nas VMs para copiá-los.

Instruções, com um exemplo estão aqui .

Você também pode usar o ovftool para converter seus modelos em .ovfpacotes, que devem ser muito compactos, e depois transferir os pacotes entre os datacenters com BITS ou FTP ou SCP ou qualquer protocolo que desejar.

Opções:

Do meu ponto de vista, tenho três abordagens possíveis, embora tenha muita esperança de que esteja perdendo uma melhor que alguém aqui possa me apontar. (Idealmente, um que me faça mover apenas os 40 GiB de dados reais e em um método recuperável, "em segundo plano" ou com aceleração de velocidade.)

1. Copie os arquivos entre os datastores por meio do cliente vSphere.
   • Vantagem: Movendo apenas ~ 40 GiB, não ~ 100 GiB.
   • Desvantagem: Tudo o resto - não resumable, não fundo / speed-estrangulada, a interface SUGA .
     
     
2. Copie o arquivo entre convidados do Windows usando o BITS
   • Vantagem: Recuperável, transferência de fundo.
   • Desvantagem: Movendo ~ 60 GiB de dados que realmente não existem.
   • Bônus: usa o PowerShell. <3
   • Bônus de liberdade condicional duplo segredo : o PowerShell Remoting torna possível fazer isso em um único comando.
     
     
3. Copie o arquivo entre hosts ESXi via SCP
   • Vantagem: Acelerado e potencialmente recuperável.
   • Desvantagem: Movendo ~ 60 GiB de dados que realmente não existem. Não é uma transferência em segundo plano.
   • Bônus: barba no pescoço. Barba de pescoço extra para retomada.
     
     
4. Melhor opção sugerida em Falha no servidor.
   • Vantagem: Transferência em segundo plano recuperável e com aceleração de velocidade que apenas move ~ 40 GiB de dados existentes.
   • Desvantagem: Atribuir um representante de custos de recompensa.
   • Bônus: Aprenda algo novo, justifique jogar ServerFault no trabalho.

Aqui está uma ideia um pouco interessante para você. Isso não ajudará na sua propagação inicial, mas me pergunto se o uso de algo como o produto gratuito da Crashplan o ajudaria com seus modelos.

https://www.code42.com/store/

Ele deduze e diferencia os níveis de bloco, para que você possa instalá-lo em um servidor local no HQ como o "semeador" e em cada servidor spoke (em uma VM, eu acho) como um "receptor". Configure os backups para incluir apenas a pasta em que os modelos serão armazenados no HQ Server. Também pode fazer backup para vários destinos (como cada "spoke") https://support.code42.com/CrashPlan/Latest/Getting_Started/Choosing_Destinations

As etapas (depois de configurar o aplicativo Crashplan de cada lado) funcionariam da seguinte forma:

1. Copie os modelos do (s) armazenamento (s) de dados para o servidor "semente" no diretório que o Crashplan está monitorando. Em uma rede de gigabit, isso pode demorar um pouco, mas não deve ser muito ruim.
2. O Crashplan deve monitorar e iniciar o backup dos arquivos nos raios / receptores. Obviamente, isso levará um bom tempo.
3. Após a propagação / backup inicial, quando os futuros modelos mudarem, copie-os do (s) armazenamento (s) de dados real (s) para o diretório do servidor "semente" que o Crashplan está monitorando, substituindo a cópia original do modelo. Em seguida, o Crashplan irá deduplicar e apenas substituir as alterações no nível do bloco nos raios.

Apenas uma idéia ... pode ser um caminho interessante para se aventurar e ver se funciona como uma replicação em nível de desduplicação / bloco de pobre para apenas esses arquivos.

Eu já fiz esse tipo de movimento de várias maneiras, mas, considerando o que você descreveu ...

FedEx ou UPS , com um toque ...

Sei que os servidores em uso são os servidores HP ProLiant e Dell PowerEdge. O VMware não possui um bom suporte para dispositivos removíveis (por exemplo, USB) como destinos do armazenamento de dados. No entanto, o uso de uma única unidade lógica RAID 0 de unidade (no HP-speak) no site principal pode funcionar. Você pode adicionar e remover discos conectados localmente nos sistemas HP e Dell e usá-lo como um meio para transportar datastores.

Sendo modelos, você pode movê-los / copiá-los para o disco local via vCenter. Envie os discos. Insira no servidor autônomo receptor. A matriz e o armazenamento de dados serão reconhecidos por meio de uma nova varredura do sistema de armazenamento. Copie dados. Lucro.

Também usei isso como meio de propagar cópias para replicação do vSphere, já que 24 horas de deltas são muito mais fáceis de gerenciar do que várias sincronizações completas.

Este é um método que eu uso com bastante frequência para esse tipo de cenário. Parece contra-intuitivo porque você está carregando arquivos de dentro de uma VM armazenada no armazenamento de dados para o próprio armazenamento de dados. No entanto, isso oferece muito mais controle sobre como a transferência é realizada.

• Use o WinRAR ou 7Zip para dividir seu modelo em pedaços de 1 GB a 2 GB.
• Crie uma VM no servidor ESXi em cada site remoto. São necessários recursos mínimos, esta é apenas uma área de preparação.
• Anexe um VMDK a cada uma dessas VMs grandes o suficiente para armazenar os dados que você está transferindo.
• Instale um sistema operacional e transfira a ferramenta de sua escolha (eu uso um servidor SFTP para isso).
• Faça o upload do modelo RAR'd para a VM de preparo.
• Descompacte o modelo RAR'd.
• Use o vSphere ou a interface do usuário da web para fazer upload do modelo da VM de preparo para o armazenamento de dados ESXI. (será uma transferência RÁPIDA).

Prós:

Ao dividir o modelo em partes menores, você reduz o risco de corrupção de dados durante a transferência. (Se um arquivo for corrompido, você só precisará fazer o upload novamente dessa parte do RAR, em vez de todo o arquivo de 40 GB.)

Você transfere apenas 40 GB (provavelmente menos, pois o RAR'ing será compactado ainda mais).

Você escolhe os utilitários de transferência ao fazer a transferência dentro do sistema operacional de sua escolha.

Contras:

Você precisa criar uma VM de teste. Facilito isso ao ter um modelo pré-criado com <1 GB e apenas uma instalação simples do sistema operacional + servidor SFTP.

A compactação / descompactação de um modelo de 40 GB levará de 4 a 6 horas, dependendo dos recursos da CPU.

Já lidei com esse mesmo problema algumas vezes e, na metade do tempo, acho muito melhor apenas construir novas máquinas no local remoto. Isto é especialmente verdade para o que chamo de máquinas "modelo". Minha versão disso é uma máquina bastante básica. Sua versão pode ser algo um pouco diferente.