Continuamos con el tema, que comenzó a considerarse en la
primera parte . Hoy hablaremos sobre las conexiones de red y los servidores de destino, presentaremos posibles opciones y opciones de planificación de infraestructura para una recuperación óptima de Instant VM Recovery. Así que bienvenido al gato.
Acerca de las conexiones de red
Por supuesto, es bueno tener un canal con un ancho de banda de 10 Gbit / s, a través del cual se transfieren los datos durante la copia de seguridad. Sin embargo, el canal es más modesto para restaurar desde una copia de seguridad, pero se recomienda utilizar el equipo de NIC con LACP o SMB Multicanal, o alguna otra opción con agregación de ancho de banda. Puede usar, por ejemplo, puertos LOM en la versión 4x1 Gbit / s. Esta configuración se recomienda para la conexión de "varios dispositivos de origen: 1 dispositivo de copia de seguridad de destino", es decir, cuando se conecta "muchos a uno". (Del mismo modo, la recuperación paralela de un almacenamiento de respaldo a los dispositivos de destino, por regla general, estos son los mismos iniciales desde los que se realizaron los respaldos, es una conexión de uno a muchos).
Por ejemplo, puede configurar múltiples trabajos de respaldo de múltiples hosts Hyper-V / LUN y guardar los respaldos en el mismo almacenamiento de destino. Si tiene 10 de estos hosts con un ancho de banda de canal total de 4x1 Gbit / s, entonces si tiene una tubería de 10Gbit / s en el dispositivo de destino, esta es una configuración bastante adecuada.
En el caso de que el almacenamiento de respaldo sea SMB share, el multicanal funciona muy bien (SMB Direct puede complementarlo si tiene NIC con soporte RDMA configurado). Estas capacidades ahora son compatibles con muchas implementaciones de clúster de Hyper-V. Sin embargo, el componente de la solución Veeam responsable del transportador de datos puede usar SMB Multicanal y SMB Direct (nuevamente, con NIC configuradas con soporte RDMA) solo en el escenario cuando usa máquinas virtuales almacenadas en SMB File share para respaldo proxy fuera del host. Estos motores de datos Veeam funcionan respectivamente en el proxy de copia de seguridad fuera del host y en el repositorio. Tal escenario se describe en detalle
aquí .
Otro punto importante: cuando se usa la formación de equipos de NIC de Windows en
modo independiente de Switch , se permite la transferencia de datos de todos los participantes y se recibe de uno solo. Si desea obtener el rendimiento óptimo en ambas direcciones para un proceso, no necesita usar LACP. Pero en este caso, debe asegurarse de que se realicen varias restauraciones en el mismo host.
Como puede ver, la agregación de ancho de banda conlleva una serie de limitaciones y no es completamente idéntica a tener un buen canal. En cualquier caso, debe basarse en escenarios de uso planificados.
Resumiendo: dependiendo de su infraestructura, puede usar la formación de equipos de NIC de Windows en LACP o en modo de conmutación independiente / modo multicanal SMB. La última opción es útil si está trabajando con el recurso compartido de archivos SMB y desea usar SMB Direct (no se olvide de las características del trabajo mencionado anteriormente).
Se necesita un alto ancho de banda y una baja latencia para proporcionar el mejor rendimiento durante el montaje de discos virtuales, al acceder y copiar datos durante Instant VM Recovery.
Puede realizar varias operaciones de recuperación al mismo tiempo y aún no detener los trabajos de copia de seguridad. Es decir, de nuevo, en presencia de un canal decente, el papel principal lo juegan los recursos informáticos y el almacenamiento. Si todo esto está diseñado correctamente para la copia de seguridad, la recuperación será efectiva.
Recomendaciones para dispositivos de destino
Considere varias opciones, de las cuales, posiblemente, elija la mejor para usted.
Opción 1: Recuperar a hosts Hyper-V y directamente al LUN en la infraestructura de producción
Incluso si tiene un sistema de almacenamiento de alto rendimiento con almacenamiento en caché de lectura / escritura o el nivel 1 está configurado, entonces, como se mencionó
en una publicación anterior , debe tener cuidado de no desbordarse. De lo contrario, las máquinas virtuales de producción se verán afectadas. Y esto puede suceder, por ejemplo, si intenta escribir grandes cantidades de datos en el sistema de almacenamiento lo más rápido posible, esto sucede al migrar los sistemas de almacenamiento. En tales operaciones, tratamos de evitar el uso de sistemas de almacenamiento de nivel 1. Consideraciones similares se aplican a la restauración de máquinas virtuales grandes.
Puede recomendar la recuperación para separar los LUN con diferentes perfiles. Las máquinas virtuales restauradas se pueden migrar lentamente a CSV de producción. Para garantizar una alta disponibilidad, puede usar el clúster mediante la migración de almacenamiento en vivo (funcionalidad de migración de almacenamiento "en vivo"). Naturalmente, debe centrarse en el rendimiento de su matriz de almacenamiento.
Opción 2: recuperación a hosts Hyper-V con unidades SSD / NMVe locales
Otro escenario de recuperación en producción, bastante efectivo: usar el host Hyper-V desde el almacenamiento local a SSD o NVMe. El tamaño del espacio en disco depende de cuántas máquinas virtuales desee recuperar durante un determinado período de tiempo y de qué tan grandes sean estas máquinas virtuales.
En teoría, es poco probable que necesite restaurar a todos y todo, por lo que esta configuración debería tener un costo bastante económico. Por ejemplo, puede usar una SSD en cada uno de los nodos del clúster, o solo en unos pocos, o en general solo en uno. Cuantos más SSD / NVMe use, más presupuesto podrá tener, mientras mantiene una distribución de carga bastante eficiente entre los hosts. En la etapa final del procedimiento de recuperación instantánea, las máquinas virtuales se pueden transferir fácilmente a CSV de producción, utilizando la misma funcionalidad de migración en vivo de almacenamiento.
El diagrama muestra una opción de planificación de infraestructura. Por supuesto, puede combinar los enfoques anteriores a su discreción.
Opción 3: Recuperar a hosts dedicados de Hyper-V con unidades SSD / NVMe locales
En esta opción, asignamos uno o más hosts específicamente para admitir la recuperación. Esto evita una posible escasez de recursos y el impacto en la operación de los hosts de producción en el clúster. Puede usar unidades NVMe. Recomendamos que pruebe las capacidades de recuperación en esta configuración de antemano para comprender cómo se están agotando los recursos.
Si planea aumentar su consumo, entonces, para la migración final de máquinas reacondicionadas a producción, puede usar la llamada migración sin compartir recursos Shared Nothing Live Migration. (Para esto, deberá establecer configuraciones de seguridad adicionales). En cuanto a los recursos de red, puede utilizar, por ejemplo, las capacidades SMB Multicanal y SMB Direct para la migración a CSV / Live Migration / S2D Hyper-V.
Sí, la migración de sistemas de almacenamiento (migración en vivo de almacenamiento) no es el proceso más rápido, es un inconveniente. Pero hay una ventaja: sus máquinas virtuales se restauran y continúan funcionando durante este proceso.
En conclusión
Por supuesto, todos eligen las opciones preferidas según cuál sea el cuello de botella en una infraestructura particular (servidor de origen, servidor de destino, recursos de red). Además, es muy posible que se requiera un estudio cuidadoso solo para planificar la recuperación de las máquinas virtuales más críticas o para aquellos consumidores que pagan por dicho servicio.
En cualquier caso, el objetivo principal siempre será la recuperación más rápida posible.
Después de eso, ya es posible migrar de forma segura al sistema de almacenamiento del clúster, lo que garantiza una alta disponibilidad y tolerancia a fallas. Y, por supuesto, las máquinas virtuales deben protegerse en forma de copia de seguridad / replicación en caso de que necesiten restaurarse nuevamente en algún momento.
¿Qué más leer?