¿Cómo debo copiar mis plantillas de VM entre los centros de datos de vSphere?

Antecedentes / Arquitectura del entorno:

Mi entorno actual $corp_overlords$está configurado en un modelo de concentrador y radio con un concentrador de oficina hogareña tecnológicamente bien dotado (SAN, clúster ESXi de Bladecenter / Bladesystem, conexión de Internet de fibra, etc.) conectado a una serie de radios de sitios remotos que están no tan bien, y normalmente contienen un único servidor host ESXi y se conectan al concentrador de la oficina en casa a través de un T1. Todo el tráfico que se origina en cualquier sitio remoto regresa a la oficina en casa a través de una "red MPLS" (que en realidad es solo un T1 que conecta el sitio remoto a la oficina en casa).

En la oficina en casa, en la SAN, tenemos una serie de plantillas de VM que he creado para implementar VM. Se almacenan en un volumen NFS, que es un almacén de datos de vSphere, conectado al objeto del centro de datos de la oficina en casa dentro de vSphere.

Cada sitio remoto tiene un objeto de centro de datos vSphere correspondiente, que contiene un objeto de almacén de datos que está conectado al almacenamiento conectado localmente en el servidor host ESXi ubicado físicamente en el sitio remoto.

Como estas plantillas de VM existen en el volumen NFS, ocupan ~ 40 GiB (aprovisionamiento fino). Como archivos en NTFS (o Linux FS), ocupan ~ 100 GiB.

Pregunta:

¿Cómo debo copiar estos 40 GiB de datos de aprovisionamiento delgado (que ocupa 100 GiB de espacio de sistema de archivos) entre mis sitios?

Estoy bajo las restricciones de que tengo aproximadamente 5 días para hacerlo, y no puedo interferir (notablemente) con el "tráfico de red normal".

¿Qué tal usar ovftool para copiar las plantillas directamente entre hosts?

He usado esto para máquinas virtuales antes, y funciona bastante bien. No estoy seguro de si eso también funciona para las plantillas, pero si no, puede convertir las plantillas temporalmente en máquinas virtuales para copiarlas.

Instrucciones, con un ejemplo están aquí .

También puede usar ovftool para convertir sus plantillas en .ovfpaquetes, que deben ser muy compactos, y luego transferir los paquetes entre centros de datos con BITS o FTP o SCP o el protocolo que desee.

Opciones:

Desde mi punto de vista, tengo tres enfoques posibles, aunque espero sinceramente perderme uno mejor que alguien aquí pueda señalarme. (Idealmente, uno que solo me tiene moviendo los 40 GiB de datos reales , y en un método reanudable, "en segundo plano" o acelerado por la velocidad).

1. Copie los archivos entre almacenes de datos a través del cliente vSphere.
   • Ventaja: Mover solo ~ 40 GiB, no ~ 100 GiB.
   • Desventaja: Todo lo demás: no reanudable, no de fondo / acelerado, la interfaz apesta .
     
     
2. Copie el archivo entre invitados de Windows usando BITS
   • Ventaja: reanudable, transferencia de fondo.
   • Desventaja: Mover ~ 60 GiB de datos que realmente no existen.
   • Bonificación: Utiliza PowerShell. <3
   • Bono de prueba doble secreto : PowerShell Remoting hace posible hacer esto en un solo comando.
     
     
3. Copie el archivo entre hosts ESXi a través de SCP
   • Ventaja: velocidad acelerada y potencialmente reanudable.
   • Desventaja: Mover ~ 60 GiB de datos que realmente no existen. No transferencia de fondo.
   • Bonificación: cuello barba. Barba extra para la reanudabilidad.
     
     
4. Mejor opción sugerida en Falla del servidor.
   • Ventaja: transferencia de fondo reanudable y acelerada que solo mueve ~ 40 GiB de datos que existen.
   • Desventaja: Otorgar una recompensa cuesta rep.
   • Bonificación: aprende algo nuevo, justifica jugar ServerFault en el trabajo.

Aquí hay una idea algo interesante para ti. No ayudará con su siembra inicial, pero me pregunto si usar algo como el producto gratuito de Crashplan lo ayudaría con sus plantillas.

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

Deduce y bloquea los diferenciales de nivel, por lo que puede instalarlo en un servidor local allí en HQ como "sembrador", y en cada servidor de radios (en una VM, supongo) como un "receptor". Configure las copias de seguridad para incluir solo la carpeta donde se almacenarán las plantillas en el servidor HQ. También puede realizar copias de seguridad en múltiples destinos (como cada "radio") https://support.code42.com/CrashPlan/Latest/Getting_Started/Choosing_Destinations

Los pasos (después de configurar la aplicación Crashplan en cada lado) funcionarían de la siguiente manera:

1. Copie las plantillas del almacén de datos al servidor "semilla" en el directorio que Crashplan está monitoreando. En una red gigabit, esto puede llevar un poco de tiempo, pero no debería ser tan malo.
2. Crashplan debería monitorear y comenzar a hacer una copia de seguridad de los archivos en los radios / receptores. Obviamente, esto llevará bastante tiempo.
3. Después de la inicialización / copias de seguridad iniciales, cuando las plantillas futuras cambien, cópielas de los almacenes de datos reales al directorio del servidor "inicial" que Crashplan está monitoreando, sobrescribiendo la copia original de la plantilla. Luego, Crashplan deducirá y solo responderá los cambios de nivel de bloque a los radios.

Solo una idea ... podría ser un camino interesante para aventurarse y ver si funciona como la replicación de nivel de deduplicación / bloqueo de un pobre solo para estos archivos.

He hecho este tipo de movimiento de varias maneras, pero dado lo que has descrito ...

FedEx o UPS , con un giro ...

Sé que los servidores en uso son servidores HP ProLiant y Dell PowerEdge. VMware no tiene un buen soporte para dispositivos extraíbles (por ejemplo, USB) como objetivos del almacén de datos. Sin embargo, usar una sola unidad de disco lógico RAID 0 (en HP-speak) en el sitio principal puede funcionar. Puede agregar y eliminar discos conectados localmente en los sistemas HP y Dell y usarlo como medio para transportar almacenes de datos.

Al ser plantillas, puede moverlas / copiarlas a su disco local a través de vCenter. Envíe los discos. Insertar en el servidor autónomo receptor. La matriz y el almacén de datos se reconocerán mediante un nuevo análisis del sistema de almacenamiento. Copiar datos Lucro.

También he usado esto como un medio para generar copias para la replicación de vSphere, ya que las 24 horas de deltas son mucho más fáciles de administrar que las múltiples sincronizaciones completas.

Este es un método que uso con bastante frecuencia para este tipo de escenario. Parece contrario a la intuición porque está cargando archivos desde el interior de una VM almacenada en el almacén de datos, en el propio almacén de datos. Sin embargo, esto le da mucho más control sobre cómo se realiza la transferencia.

• Use WinRAR o 7Zip para dividir su plantilla en fragmentos de 1GB-2GB.
• Cree una máquina virtual en el servidor ESXi en cada sitio remoto. Se necesitan recursos mínimos, esto es solo un área de preparación.
• Adjunte un VMDK a cada una de estas máquinas virtuales que sea lo suficientemente grande como para contener los datos que está transfiriendo.
• Instale un sistema operativo y la herramienta de transferencia de su elección (utilizo un servidor SFTP para esto).
• Cargue la plantilla RAR'd en la VM provisional.
• Descomprima la plantilla RAR'd.
• Use vSphere o la interfaz de usuario web para cargar la plantilla desde la VM provisional al almacén de datos de ESXI. (Esta será una transferencia RÁPIDA).

Pros:

Al dividir la plantilla en partes más pequeñas, reduce el riesgo de corrupción de datos durante la transferencia. (Si un archivo se corrompe, solo necesita volver a cargar esa parte del RAR, en lugar del archivo completo de 40 GB).

Solo transfieres 40 GB (probablemente menos, ya que RAR'ing se comprimirá aún más).

Puede elegir entre las utilidades de transferencia mientras realiza la transferencia dentro del sistema operativo que elija.

Contras:

Tienes que crear una máquina virtual provisional. Hago esto más fácil al tener una plantilla pre-creada que es <1GB que solo tiene una instalación de sistema operativo + servidor SFTP.

Comprimir / descomprimir una plantilla de 40GB tomará ~ 4-6 horas dependiendo de los recursos de su CPU.

He tratado este mismo problema varias veces y aproximadamente la mitad del tiempo me parece que estoy mucho mejor solo para construir nuevas máquinas en la ubicación remota. Esto es especialmente cierto para lo que yo llamo máquinas "plantilla". Mi versión de eso es una máquina bastante básica. Su versión puede ser algo un poco diferente.