Conmutación por error y conmutación por recuperación
Azure Site Recovery ofrece la flexibilidad de conmutar por error a Azure si se produce un desastre, así como de conmutar por recuperación a máquinas locales cuando el evento termina.
Ahora quiere realizar una conmutación por error completa en el resto del entorno protegido en Azure. Las conmutaciones por error completas hay que realizarlas después de haber ejecutado correctamente un simulacro de conmutación por error en una sola máquina virtual de prueba. Después de que la conmutación por error se haya completado correctamente, se realizará la conmutación por recuperación.
En esta unidad, explorará las diferencias entre conmutación por error y conmutación por recuperación. También verá cómo se crea una directiva de conmutación por recuperación automáticamente después de configurar una directiva de replicación en Azure.
Conmutación por error y conmutación por recuperación
Una conmutación por error es el proceso que tiene lugar cuando se toma la decisión de invocar el plan de BCDR de la empresa. La conmutación por error se produce cuando el entorno activo actual, que está protegido con Site Recovery, se mueve al entorno de réplica. Este entorno de réplica de destino ocupa el lugar del entorno activo y se convierte en la infraestructura primaria.
Una conmutación por recuperación sucede a la inversa de una conmutación por error. El entorno activo anterior (que ahora es el entorno de réplica, porque ha habido una conmutación por error) revierte su rol original y vuelve a convertirse en el entorno activo. Una vez que se ha producido la conmutación por error en la primera instancia, es necesario que haya una etapa de reprotección. En esta fase, el entorno original se vuelve a sincronizar con el nuevo entorno activo. Este proceso permite que se produzcan la conmutación por error y la conmutación por recuperación sin pérdida de datos. Es probable que la fase de reprotección sea un proceso largo, ya que es necesario constatar que el entorno activo anterior funciona correctamente después del desastre.
Las cuatro fases de las acciones de una conmutación por error y una conmutación por recuperación son:
- Conmutación por error a Azure: si el sitio primario local deja de funcionar, se toma la decisión de conmutar por error a Azure (o al sitio secundario), creando máquinas virtuales a partir de los datos replicados principales.
- Reprotección de las máquinas virtuales de Azure: una vez que ha tenido lugar la conmutación por error, las máquinas virtuales de Azure se deben volver a proteger para que puedan replicar los cambios de nuevo en el entorno local, una vez evitado el desastre. Las máquinas virtuales se apagan para garantizar la coherencia de los datos.
- Conmutación por recuperación a un entorno local: cuando se ha hecho una copia de seguridad del sitio local y este se encuentra en funcionamiento, es posible conmutar por error a ese entorno. Al hacerlo, dicho entorno volverá a ser el entorno activo. La conmutación por recuperación no se puede realizar a un servidor físico. Todos los sistemas se deben conmutar por recuperación en las máquinas virtuales.
- Reprotección de las máquinas virtuales locales: esta acción de volver a proteger las máquinas virtuales locales tiene lugar para que empiecen a replicarse en Azure después de que la conmutación por recuperación se haya producido correctamente.
Directivas de conmutación por recuperación
Cuando se crea una directiva de replicación local para copiar las máquinas locales en Azure, se crea automáticamente una directiva de conmutación por recuperación asociada. La directiva tiene algunos atributos fijos que no se pueden cambiar, a saber:
- Solo se puede volver a replicar en el servidor de configuración local.
- El objetivo de punto de recuperación está establecido en 15 minutos.
- La retención del punto de recuperación está establecida en 24 horas.
- Las instantáneas coherentes con las aplicaciones están establecidas en cada hora.
La ejecución de la conmutación por recuperación detiene las máquinas virtuales de Azure. Una vez finalizada la replicación, inicie la VM local para que se encargue de las cargas de trabajo. El servicio se interrumpe, por lo que conviene programar la conmutación por recuperación en un momento que no afecte al negocio.
Planes de continuidad empresarial y recuperación ante desastres
Los planes de BCDR de Site Recovery permiten la personalización y la secuenciación de la conmutación por error y la conmutación por recuperación de las máquinas virtuales y de las aplicaciones que se ejecutan en ellas. Las máquinas se agrupan, y las acciones de recuperación se pueden automatizar con el uso de scripts durante la conmutación por error o la conmutación por recuperación. También puede agregar más pasos manuales de acciones si es necesario. Si prueba el plan de BCDR antes de que se produzca un desastre, tendrá más confianza en un resultado positivo. Debe lograr que la infraestructura vuelva a estar en funcionamiento en la ubicación secundaria rápidamente para cumplir el objetivo de tiempo de recuperación de la empresa.
Conmutaciones por error flexibles
Con la posibilidad de ser flexible con las conmutaciones por error, Site Recovery puede ejecutar conmutaciones por error a petición con fines de prueba. Aislar estas pruebas significa que no se interrumpen los servicios activos. Esta flexibilidad también permite que se ejecute una conmutación por error durante una interrupción planeada del servicio activo. Los usuarios del sistema no percibirán ninguna caída debido a la interrupción, ya que se les conmuta automáticamente al entorno replicado. La flexibilidad también funciona a la inversa. La conmutación por recuperación a petición puede ser parte de una prueba planeada o parte de un escenario de recuperación ante desastres completamente invocado.