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

Question

Arquitetura de plano de fundo / ambiente:

Meu ambiente atual para $corp_overlords$ está configurado em um modelo hub-and-spoke com um hub de escritório doméstico tecnologicamente bem dotado (SAN, cluster bladecenter / bladesystem ESXi, conexão de fibra óptica, etc.) conectado a um número de spokes de sites remotos que não são tão bem-sucedidos e geralmente contêm um único servidor host ESXi e se conectam ao hub do home office por meio de um T1. Todo o tráfego originado em qualquer site remoto é encaminhado de volta ao escritório doméstico através de uma "rede MPLS" (que é na verdade apenas um T1 conectando o site remoto ao escritório doméstico).

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

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

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

Pergunta:

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 que tenho aproximadamente 5 dias para fazer isso e não posso interferir (visivelmente) com "tráfego de rede normal".

    

Answer 1

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

Eu 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 simplesmente converter os modelos temporariamente em VMs para copiá-los.

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

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

    

Answer 2

Opções:

Do jeito que eu vejo, eu tenho três abordagens possíveis, embora eu sinceramente espero que eu esteja perdendo uma melhor que alguém aqui possa me apontar. (O ideal é que eu só mova os dados de 40 GiB de real e em um método recuperável de "plano de fundo" ou de limitaçã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 mais - não é recuperável, não é plano de fundo / acelerado, interface SUCKS .
     
     
2. Copie o arquivo entre os convidados do Windows usando o BITS
   • Vantagem: Retirada, transferência em segundo plano.
   • Desvantagem: mover ~ 60 GiB de dados que realmente não existem.
   • Bônus: usa o PowerShell. < 3
   Prémio Double Secret Probation Bónus: o PowerShell Remoting permite fazê-lo num único comando.
   
   
3. Copie o arquivo entre hosts ESXi via SCP
   • Vantagem: acelerada por velocidade e potencialmente recuperável.
   • Desvantagem: Movendo ~ 60 GiB de dados que realmente não existem. Não transferência de fundo.
   • Bônus: barba no pescoço. Barba na nuca extra para ressumabilidade.
     
     
4. Melhor opção sugerida na falha do servidor.
   • Vantagem: Transferência em segundo plano retomável e acelerada que movimenta apenas ~ GiB de dados que existem.
   • Desvantagem: atribuir um representante de custos de recompensa
   • Bônus: aprenda algo novo, justifique jogar o ServerFault no trabalho.

Answer 3

Aqui está uma ideia interessante para você. Não ajudará em sua semeadura inicial, mas eu me pergunto se usar algo como o produto gratuito da Crashplan poderia ajudá-lo com seus modelos.

link

Ele desduplica e bloqueia diferenciais de nível, então você pode instalá-lo em um servidor local lá 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 na qual os modelos serão armazenados no servidor do HQ. Ele também pode fazer backup para vários destinos (como cada "spoke") link

As etapas (depois de configurar o aplicativo Crashplan em cada lado) funcionariam como:

1. Copie os modelos do (s) armazenamento (s) de dados para o servidor "semente" para o diretório em que o Crashplan está monitorando. Em uma rede gigabit, isso pode levar um pouco de tempo, mas não deve ser tão ruim.
2. A Crashplan deve monitorar e iniciar o backup dos arquivos para os raios / receptores. Isso obviamente levará um bom tempo.
3. Após a propagação / backup inicial, quando os futuros modelos alteram a cópia deles do (s) armazenamento (s) de dados real para o diretório do servidor "seed", o Crashplan está monitorando, sobrescrevendo a cópia do modelo original. Em seguida, a Crashplan irá deduzir e apenas replica as alterações de nível de 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 bloco / desduplicação de um homem pobre apenas para esses arquivos.

    

Answer 4

Eu 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 servidores HP ProLiant e Dell PowerEdge. O VMware não tem um bom suporte para dispositivos removíveis (por exemplo, USB) como destinos de armazenamento de dados. No entanto, o uso de uma unidade lógica RAID 0 de unidade única (no HP-speak) no site principal can funciona. Você pode adicionar e remover discos conectados localmente nos sistemas HP e Dell e usá-los como meio de transportar datastores.

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

Também usei isso como um meio de distribuir cópias para a 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.

    

Answer 5

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

• Use o WinRAR ou o 7Zip para dividir seu modelo em partes de 1 GB a 2 GB.
• Crie uma VM no servidor ESXi em cada site remoto. São necessários recursos mínimos, isso é apenas uma área de preparação.
• Anexe um VMDK a cada uma dessas VMs que seja grande o suficiente para conter os dados que você está transferindo.
• Instale um SO e uma ferramenta de transferência de sua escolha (eu uso um servidor SFTP para isso).
• Faça upload do modelo de RAR para a VM de preparação.
• Descompacte o modelo de RAR.
• Use a interface do usuário do vSphere ou da web para fazer o upload do modelo da VM de armazenamento temporário para o armazenamento de dados do ESXI. (esta 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á reenviar aquele pedaço do RAR, em vez de todo o arquivo de 40GB.)

Você só transfere 40 GB (provavelmente menos, pois o RAR vai aumentar ainda mais).

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

Contras:

Você precisa criar uma VM temporária. Facilito isso com um modelo pré-criado de < 1GB que possui apenas um servidor de instalação + SFTP simples.

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

    

Answer 6

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