Reprotección de máquinas virtuales de Azure conmutadas por error en la región principal

Si se conmutan por error las máquinas virtuales de Azure desde una región a otra mediante Azure Site Recovery, estas arrancan en la región secundaria, en estado desprotegido. Si quiere conmutar por recuperación las máquinas virtuales a la región primaria, realice las siguientes tareas:

1. Vuelva a proteger las máquinas virtuales en la región secundaria, para que empiecen a replicarse en la región primaria.
2. Una vez completada la reprotección y después de que las máquinas virtuales se repliquen, puede realizar una conmutación por error desde la región secundaria a la primaria.

Requisitos previos

• La conmutación por error de máquinas virtuales de la región principal a la secundaria se debe confirmar.
• El sitio de destino principal debe estar disponible y, además, debe tener la posibilidad de acceder o crear recursos en dicha región.

Reprotección de máquinas virtuales

1. En Almacén>Elementos replicados, haga clic con el botón derecho en la máquina virtual que se conmutó por error y, luego, seleccione Volver a proteger. La dirección de reprotección debe mostrarse desde la ubicación secundaria a la principal.

   

2. Revise el grupo de recursos, la red, el almacenamiento y los conjuntos de disponibilidad. Después, seleccione Aceptar. Si hay algún recurso marcado como nuevo, se crea como parte del proceso de reprotección.

3. Este trabajo de reprotección inicializa el sitio de destino con los datos más recientes. Una vez finalizado el proceso, se produce la replicación diferencial. Después, puede conmutar por recuperación al sitio principal. Puede seleccionar la cuenta de almacenamiento o la red que desea usar durante la reprotección mediante la opción de personalización.

   

Personalización de la configuración de reprotección

Puede personalizar las siguientes propiedades de la máquina virtual de destino durante la reprotección.

¿Qué ocurre durante la reprotección?

De forma predeterminada, sucede lo siguiente:

1. Se crea una cuenta de almacenamiento en caché en la región en la que se ejecuta la máquina virtual en la que se ha realizado la conmutación por error.
2. Si la cuenta de almacenamiento de destino (la cuenta de almacenamiento original de la región principal) no existe, se crea una. El nombre asignado a la cuenta de almacenamiento se corresponde con el nombre de la cuenta de almacenamiento que usa la máquina virtual secundaria, pero incluye el sufijo asr.
3. Si la máquina virtual usa discos administrados, se crean discos administrados de réplica en la región primaria para almacenar los datos replicados de los discos de la máquina virtual secundaria.
4. Se crean réplicas temporales de los discos de origen (discos conectados a las máquinas virtuales en la región secundaria) con el nombre ms-asr-<GUID> que se usan para transferir o leer datos. Los discos temporales nos permiten usar el ancho de banda completo del disco, en lugar de solo el 16 % del ancho de banda de los discos originales (que están conectados a la máquina virtual). Los discos temporales se eliminan una vez completada la reprotección.
5. Si el conjunto de disponibilidad de destino no existe, se crea uno como parte del trabajo de reprotección, en caso de que sea necesario. Si personalizó la configuración de reprotección, en este caso se usa el conjunto seleccionado.

Cuando se desencadena un trabajo de reprotección y la máquina virtual de destino ya existe, ocurre lo siguiente:

1. La máquina virtual de destino se apaga en caso de que esté en ejecución.
2. Si la máquina virtual utiliza discos administrados, se crea una copia del disco original con el sufijo -ASRReplica. Los discos originales se eliminan. Las copias de -ASRReplica se usan para la replicación.
3. Si la máquina virtual usa discos no administrados, los discos de datos de la máquina virtual de destino se desasocian y se usan para la replicación. Se crea una copia del disco del sistema operativo y se adjunta a la máquina virtual. El disco del sistema operativo original se separa y se usa para la replicación.
4. Solo se sincronizan los cambios entre el disco de origen y el disco de destino. Las copias de seguridad diferenciales se calculan comparando los discos y, a continuación, se transfieren. Consulte a continuación para averiguar el tiempo estimado para completar la reprotección.
5. Cuando finaliza el trabajo de sincronización, comienza la replicación diferencial y se crea un punto de recuperación según la directiva de replicación.

Cuando se desencadena un trabajo de reprotección y no existen ni la máquina virtual ni los discos de destino no existen, ocurre lo siguiente:

1. Si la máquina virtual usa discos administrados, los discos de réplica se crean con el sufijo -ASRReplica. Las copias de -ASRReplica se usan para la replicación.
2. Si la máquina virtual usa discos no administrados, los discos de réplica se crean en la cuenta de almacenamiento de destino.
3. Todos los discos se copian de la región que ha conmutado por error a la nueva región de destino.
4. Cuando finaliza el trabajo de sincronización, comienza la replicación diferencial y se crea un punto de recuperación según la directiva de replicación.

Tiempo estimado para realizar la reprotección

En la mayoría de los casos, Azure Site Recovery no replica los datos completos en la región de origen. La cantidad de datos replicados depende de las condiciones siguientes:

1. Azure Site Recovery no admite la reprotección si los datos de la máquina virtual de origen se eliminan, dañan o no son accesibles por algún motivo. Por ejemplo, un grupo de recursos cambia o elimina. Como alternativa, puede deshabilitar la protección de recuperación ante desastres anterior y habilitar una nueva protección de la región actual.
2. Si se puede acceder a los datos de la máquina virtual de origen, para calcular los diferenciales se comparan ambos discos y solo se transfieren las diferencias. En este caso, el tiempo de reprotección es mayor o igual a checksum calculation time + checksum differentials transfer time + time taken to process the recovery points from Azure Site Recovery agent + auto scale time.

Factores que rigen el tiempo de reprotección en el escenario 2

Los siguientes factores afectan al tiempo de reprotección cuando se puede acceder a la máquina virtual de origen en el escenario 2:

1. Tiempo de cálculo de suma de comprobación: el tiempo necesario para completar el proceso de habilitación de la replicación de la ubicación primaria a la ubicación de recuperación ante desastres se usa como punto de referencia para el cálculo diferencial de suma de comprobación. Vaya a Almacenes de Recovery Services>Supervisión>Trabajos de Site Recovery para ver el tiempo necesario para completar el proceso de habilitación de la replicación. Este será el tiempo mínimo necesario para completar el cálculo de la suma de comprobación.

2. La transferencia diferencial de datos de suma de comprobación se produce aproximadamente en el 23 % del rendimiento del disco.

3. El tiempo necesario para procesar los puntos de recuperación enviados desde el agente de Azure Site Recovery: el agente de Azure Site Recovery continúa enviando puntos de recuperación durante la fase de cálculo de suma de comprobación y transferencia. Sin embargo, Azure Site Recovery los procesa solo una vez completada la transferencia diferencial de suma de comprobación. El tiempo necesario para procesar los puntos de recuperación será de aproximadamente un quinto (1/5) del tiempo necesario para el cálculo diferencial de suma de comprobación y el tiempo de transferencia diferencial de suma de comprobación (tiempo para el cálculo diferencial de suma de comprobación + tiempo para la transferencia diferencial de suma de comprobación). Por ejemplo, si el tiempo necesario para el cálculo diferencial de suma de comprobación y la transferencia diferencial de suma de comprobación es de 15 horas, el tiempo necesario para procesar los puntos de recuperación del agente será de tres horas.

4. El tiempo de escalado automático es de aproximadamente entre 20 y 30 minutos.

Escenario de ejemplo:

Vamos a tomar el ejemplo de la captura de pantalla siguiente, donde Habilitar replicación desde la ubicación primaria a la ubicación de recuperación ante desastres tardó una hora y 12 minutos. El tiempo de cálculo de suma de comprobación será de al menos una hora y 12 minutos. Suponiendo que la cantidad de cambio de datos después de la conmutación por error es de 45 GB y el disco tiene un rendimiento de 60 Mbps, la transferencia diferencial se producirá a 14 Mbps y el tiempo necesario para la transferencia diferencial será de 45 GB/14 Mbps, que es aproximadamente 55 minutos. El tiempo necesario para procesar los puntos de recuperación es de aproximadamente un quinto del tiempo total necesario para el cálculo de suma de comprobación (72 minutos) y el tiempo necesario para la transferencia de datos (55 minutos), que es aproximadamente 25 minutos. Además, el escalado automático tarda entre 20 y 30 minutos. Por lo tanto, el tiempo total de reprotección debe ser de al menos tres horas.

Lo anterior es una ilustración sencilla de cómo calcular el tiempo de reprotección.

Cuando la máquina virtual se ha vuelto a proteger de la región de la recuperación ante desastres a la región primaria (es decir, después de que se produzca la conmutación por error desde la región primaria a la región de recuperación ante desastres), se eliminan la máquina virtual de destino (la máquina virtual de origen original) y las tarjetas de interfaz de red asociadas.

Sin embargo, cuando la máquina virtual se vuelve a proteger de la región primaria a la región de recuperación ante desastres después de la conmutación por error, no se elimina la máquina virtual ni las NIC asociadas de la región de recuperación ante desastres que se crearon durante la conmutación por error anterior.

Pasos siguientes

Una vez que la máquina virtual esté protegida, puede iniciar una conmutación por error. La conmutación por error apaga la máquina virtual en la región secundaria y se crea y arranca la máquina virtual en la región primaria, con un breve tiempo de inactividad durante el proceso. Se recomienda elegir una hora adecuada para el proceso y ejecutar una prueba de conmutación por error antes de iniciar una conmutación por error completa al sitio principal.

Más información sobre la conmutación por error de Azure Site Recovery