Come devo copiare i miei modelli di VM tra i datacenter vSphere?

Architettura di sfondo / ambiente:

Il mio ambiente attuale per $corp_overlords$è impostato in un modello hub-e-raggio con un hub home office tecnologicamente ben attrezzato (SAN, cluster ESXi bladecenter / bladesystem, connessione Internet in fibra ottica, ecc.) Collegato a un numero di raggi del sito remoto che sono non molto benestante, e in genere contiene un singolo server host ESXi e si collega all'hub dell'home office tramite un T1. Tutto il traffico proveniente da qualsiasi sito remoto viene reindirizzato all'home office tramite una "rete MPLS" (che in realtà è solo un T1 che collega il sito remoto all'home office).

A casa, sulla SAN, abbiamo una serie di modelli di macchine virtuali che ho creato per distribuire macchine virtuali da. Sono memorizzati in un volume NFS, ovvero un archivio dati vSphere, collegato all'oggetto centro dati dell'home office all'interno di vSphere.

Ogni sito remoto ha un oggetto vSphere datacenter corrispondente, contenente un oggetto archivio dati collegato alla memoria collegata localmente sul server host ESXi che si trova fisicamente sul sito remoto.

Poiché questi modelli di VM sono presenti sul volume NFS, occupano ~ 40 GiB (thin provisioning). Come file su NTFS (o un FS Linux), occupano ~ 100 GiB.

Domanda:

Come devo copiare questi 40 GiB di dati thin-provisioning (che occupano 100 GiB di spazio nel filesystem) tra i miei siti?

Sono soggetto ai vincoli che ho circa 5 giorni per farlo e non posso interferire (in modo evidente) con il "normale traffico di rete".

Che ne dici di usare ovftool per copiare i template direttamente tra host?

L'ho già usato per VM, e funziona abbastanza bene. Non sono sicuro che funzioni anche per i modelli, ma in caso contrario puoi semplicemente convertire temporaneamente i modelli in VM per copiarli.

Le istruzioni, con un esempio, sono qui .

Puoi anche usare ovftool per convertire i tuoi modelli in .ovfpacchetti, che dovrebbero essere molto compatti, e quindi trasferire i pacchetti tra data center con BITS o FTP o SCP o qualunque protocollo tu voglia.

Opzioni:

Per come la vedo, ho tre possibili approcci, anche se spero vivamente di perderne uno migliore a cui qualcuno qui può indicarmi. (Idealmente uno che mi fa spostare solo i 40 GiB di dati effettivi , e in un metodo di "background" o accelerato ripristinabile.)

1. Copia i file tra i datastore tramite il client vSphere.
   • Vantaggio: spostamento di soli ~ 40 GiB, non ~ 100 GiB.
   • Svantaggio: tutto il resto - non ripristinabile, non in background / limitazione della velocità, interfaccia SUCKS .
     
     
2. Copia il file tra guest Windows usando BITS
   • Vantaggio: ripresa, trasferimento in background.
   • Svantaggio: spostamento di circa 60 GiB di dati che in realtà non esistono.
   • Bonus: utilizza PowerShell. <3
   • Doppio bonus probation segreto : PowerShell Remoting consente di farlo in un solo comando.
     
     
3. Copia il file tra host ESXi tramite SCP
   • Vantaggio: accelerazione della velocità e potenziale ripresa.
   • Svantaggio: spostamento di circa 60 GiB di dati che in realtà non esistono. Non trasferimento in background.
   • Bonus: barba al collo. Barba collo extra per la ripresa.
     
     
4. Opzione migliore suggerita su Server Fault.
   • Vantaggio: trasferimento in background ripristinabile con limitazione della velocità che sposta solo ~ 40 GiB di dati esistenti.
   • Svantaggio: l'assegnazione di un rappresentante costa taglie.
   • Bonus: scopri qualcosa di nuovo, giustifica la riproduzione di ServerFault al lavoro.

Ecco un'idea abbastanza interessante per te. Non ti aiuterà con il seeding iniziale, ma mi chiedo se usare qualcosa come il prodotto gratuito di Crashplan ti aiuterebbe con i tuoi template.

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

Esegue la deduplicazione e il blocco dei differenziali di livello, quindi è possibile installarlo su un server locale lì in HQ come "seeder", e su ogni server dei raggi (in una VM immagino) come "ricevitore". Configurare i backup in modo da includere solo la cartella in cui i modelli verranno archiviati sul server HQ. Può anche eseguire il backup su più destinazioni (come ogni "raggio") https://support.code42.com/CrashPlan/Latest/Getting_Started/Choosing_Destinations

I passaggi (dopo aver configurato l'app Crashplan su ciascun lato) avrebbero funzionato in questo modo:

1. Copiare i modelli dagli archivi dati sul server "seed" nella directory su cui Crashplan sta monitorando. Su una rete gigabit questo potrebbe richiedere un po 'di tempo ma non dovrebbe essere così male.
2. Crashplan dovrebbe monitorare e iniziare il backup dei file sui raggi / ricevitori. Questo richiederà ovviamente un po 'di tempo.
3. Dopo il seeding / backup iniziale, quando cambiano i modelli futuri copiarli dall'archivio o dai datastore effettivi alla directory del server "seed" Crashplan sta monitorando, sovrascrivendo la copia del modello originale. Quindi Crashplan eseguirà la deduplicazione e sostituirà solo le modifiche del livello di blocco ai raggi.

Solo un'idea ... potrebbe essere una strada interessante per avventurarsi verso il basso e vedere se funziona come una replica a livello di dedupi / blocchi di un povero per questi file.

Ho fatto questo tipo di mossa in diversi modi, ma dato quello che hai descritto ...

FedEx o UPS , con una svolta ...

So che i server in uso sono i server HP ProLiant e Dell PowerEdge. VMware non ha un buon supporto per i dispositivi rimovibili (ad es. USB) come target del datastore. Tuttavia, utilizzando un'unità logica singola unità RAID 0 (in HP-parlare) presso il sito principale può lavorare. È possibile aggiungere e rimuovere dischi collegati localmente su sistemi HP e Dell e utilizzarlo come mezzo per trasportare archivi di dati.

Essendo modelli, è possibile spostarli / copiarli sul disco locale tramite vCenter. Spedisci i dischi. Inserire nel server autonomo ricevente. L'array e il datastore verranno riconosciuti tramite una nuova scansione del sistema di archiviazione. Copia i dati. Profitto.

Ho anche usato questo come mezzo per eseguire il seeding delle copie per la replica di vSphere, poiché 24 ore di delta sono molto più facili da gestire rispetto a più sincronizzazioni complete.

Questo è un metodo che uso abbastanza spesso per questo tipo di scenario. Sembra controintuitivo perché si stanno caricando file dall'interno di una macchina virtuale archiviata nell'archivio dati, nell'archivio dati stesso. Tuttavia, questo ti dà un controllo molto maggiore su come viene eseguito il trasferimento.

• Utilizzare WinRAR o 7Zip per suddividere il modello in blocchi da 1 GB-2 GB.
• Creare una macchina virtuale sul server ESXi in ciascun sito remoto. Sono necessarie risorse minime, questa è solo un'area di gestione temporanea.
• Collega un VMDK a ciascuna di queste VM sufficientemente grande da contenere i dati che stai trasferendo.
• Installa un sistema operativo e uno strumento di trasferimento a tua scelta (per questo uso un server SFTP).
• Carica il modello RAR sulla VM di gestione temporanea.
• Decomprimi il modello RAR.
• Utilizzare vSphere o l'interfaccia utente Web per caricare il modello dalla VM di gestione temporanea nell'archivio dati ESXI. (questo sarà un trasferimento VELOCE).

Professionisti:

Rompendo il modello in pezzi più piccoli si riduce il rischio di corruzione dei dati durante il trasferimento. (Se un file viene danneggiato, devi solo ricaricare quel pezzo di RAR, piuttosto che l'intero file da 40 GB.)

Trasferisci solo 40 GB (probabilmente meno dato che RAR comprime ulteriormente).

Puoi scegliere le utility di trasferimento mentre stai eseguendo il trasferimento all'interno del sistema operativo di tua scelta.

Contro:

Devi creare una VM di gestione temporanea. Lo rendo più semplice avendo un modello pre-creato che è <1 GB che ha solo un'installazione del sistema operativo + server SFTP.

La compressione / decompressione di un modello da 40 GB richiederà ~ 4-6 ore a seconda delle risorse della CPU.

Ho affrontato lo stesso problema un paio di volte e circa la metà delle volte trovo che sto molto meglio solo per costruire nuove macchine nella posizione remota. Ciò è particolarmente vero per quelle che chiamo macchine "modello". La mia versione è una macchina piuttosto semplice. La tua versione potrebbe essere qualcosa di leggermente diverso.