A pesar de todo el trabajo que hemos realizado en torno a VMware vSAN en términos de contenido del sitio y reseñas, puede que a algunos les sorprenda que no hayamos estado utilizando vSAN en producción. Tras la renovación de nuestros servidores de laboratorio (12x Dell EMC PowerEdge R740xd ), decidimos solucionar este problema reutilizando algunos servidores PowerEdge R730 y SSD adicionales que teníamos disponibles. El resultado es una configuración modesta de vSAN 6.6 que utilizaremos para alojar las máquinas virtuales necesarias para las pruebas, además de servir como plataforma para probar e informar sobre las nuevas características de vSAN. Sin embargo, esta implementación plantea una pregunta inmediata que los compradores de vSAN suelen hacerse: ¿cómo migro las cargas de trabajo existentes a vSAN?
Al igual que con la mayoría de las empresas, nuestro almacenamiento de laboratorio principal es una combinación de recursos compartidos iSCSI y almacenamiento de canal de fibra con la mayoría de nuestros datos que residen en arreglos Dot Hill y Fusion-io ION. Hay varias formas diferentes de abordar esta migración, desde mover máquinas virtuales entre almacenes de datos con un comando SVMotion básico con el almacenamiento conectado localmente a un host que puede ver ambos almacenes de datos, o una migración de dos pasos en la que cambian tanto el host como el almacén de datos.
Si tiene una matriz de almacenamiento con iSCSI LUN, este proceso es bastante sencillo. Agregue el dispositivo de almacenamiento iSCSI a uno de sus hosts de vSAN si aún no lo ha hecho, agregue el objetivo iSCSI desde su arreglo de almacenamiento y acceda rápidamente a esa VM dentro del clúster de vSAN sin siquiera tener que migrar el almacén de datos todavía. Si tiene una matriz de almacenamiento que se comunica a través de FC, puede aprovechar un FC HBA si ya existe uno dentro de su servidor, o agregar uno al host. Si el almacenamiento FC no se usará mucho en el futuro, el costo y el tiempo de inactividad asociados con la instalación del HBA podrían no valer la pena, si ese es el caso, pasamos al proceso de dos pasos.
Al mover máquinas virtuales entre hosts ESXi donde la computación y el almacenamiento cambiarán en el mismo movimiento, puede mover la máquina virtual a cualquier lugar de su entorno siempre que los dispositivos puedan comunicarse entre sí dentro de su vCenter. Esta es una opción que tiene la mayor compatibilidad, pero puede que no sea la ruta de transferencia más rápida si ya existe una nativa. Para máquinas virtuales individuales o grupos pequeños, esto puede no ser un problema, pero con máquinas virtuales bastante grandes o lotes grandes, se puede garantizar una ruta de transferencia más rápida.
En nuestro caso, podemos ver que la transferencia de la VM tomó solo unos minutos, con el enlace de red 10G entre los dos hosts ayudando a aumentar las velocidades hasta alrededor de 400 MB/s. En general, este es uno de los pasos más fáciles asociados con la puesta en marcha de su plataforma vSAN, pero hay algunas formas de abordarlo según sus necesidades o capacidades de hardware.
En este artículo hemos hablado extensamente sobre la facilidad de migrar archivos VMDK de VMware y recursos compartidos iSCSI existentes a vSAN. En cualquier organización que ya esté virtualizada, este proceso es bastante sencillo. VMware también cuenta con una herramienta para migraciones desde hardware físico; nosotros utilizamos VMware vCenter Converter para virtualizar cargas de trabajo heredadas. Independientemente del método utilizado, vSAN ofrece importantes ventajas en términos de eficiencia operativa y ahorro en el costo total de propiedad (TCO) en comparación con las implementaciones de TI tradicionales. Estamos entusiasmados por comprobar estos beneficios en nuestro laboratorio y esperamos publicar más contenido sobre experiencias reales.
Amazon