Conmutación por error Vs Failback: Diferencias clave en la recuperación ante desastres
En el mundo moderno, cualquier empresa puede sufrir de vez en cuando la corrupción de los datos y la interrupción de las operaciones de misión crítica. Sin embargo, incluso una breve interrupción de los servicios puede minar la confianza de los clientes y, a la larga, provocar pérdidas importantes. Las empresas, especialmente las que ejecutan sus servicios en máquinas virtuales, deben crear un plan de recuperación ante desastres (DR) de máquinas virtuales para garantizar una alta disponibilidad y la continuidad del negocio. Esta entrada del blog describe el papel de la conmutación por error y la conmutación por recuperación en el proceso de recuperación ante desastres y analiza cómo puede utilizar estas estrategias para proteger su empresa.
¿Qué es la recuperación ante desastres con máquinas virtuales?
La recuperación ante desastres es el proceso de devolver la infraestructura de su empresa a un estado normal tras una catástrofe. Una catástrofe puede ser cualquier suceso que ponga en peligro el funcionamiento de una organización, ya sean peligros naturales o provocados por el hombre. En esencia, la recuperación ante desastres de máquinas virtuales tiene por objeto restaurar el entorno virtualizado de una organización. El objetivo último de cualquier proceso de DR es reanudar casi al instante las operaciones de negocio y asegurar los datos más críticos para garantizar la continuidad de la empresa.
Las medidas de RD se dividen en tres tipos. Las medidas preventivas tienen por objeto evitar que se produzca un suceso. Las medidas correctoras pretenden arreglar un sistema en caso de desastre. Se utilizan medidas de detección para identificar posibles riesgos y mitigarlos.
Diferencia entre conmutación por error y conmutación por recuperación
Las catástrofes casi siempre ocurren de forma inesperada. En un evento de DR, es fundamental restaurar la infraestructura virtualizada de su empresa lo antes posible, antes de que se produzcan daños importantes. La conmutación por error y la conmutación por recuperación pueden ayudar a garantizar que su empresa siga funcionando correctamente, incluso si el sitio de producción se ve afectado por un desastre.
¿Qué es la conmutación por recuperación?
La conmutación por recuperación es el proceso de transferir cargas de trabajo de misión crítica desde el centro de producción primario y recuperar el sistema en una ubicación externa. El principal objetivo de la conmutación por recuperación es mitigar el impacto negativo de una catástrofe o interrupción del servicio en los servicios empresariales y los clientes. Cuando se produce un fallo de software o hardware, puede recuperar rápidamente una máquina virtual afectada pasando a su réplica.
Conmutación por recuperación mediante réplicas de máquinas virtuales
Durante la conmutación por recuperación, se enciende una réplica de la máquina virtual en un sitio remoto para sustituir a la máquina virtual original en el sitio de producción. Puede conmutar por error al último punto de recuperación, que esencialmente representa una máquina virtual en un momento determinado. Ejecutar jobs de replicación con la mayor frecuencia posible permite crear múltiples puntos de recuperación, lo que garantiza una pérdida mínima de datos en caso de desastre. La conmutación por réplica es una solución rentable adecuada para la recuperación ante desastres en caso de fallo de hardware o software.
Conmutación por recuperación en clústeres
Un clúster de conmutación por recuperación representa un grupo de ordenadores independientes que trabajan juntos para garantizar una alta disponibilidad de aplicaciones y servicios. Un clúster de conmutación por recuperación consta de dos o más servidores (o nodos) interconectados, en los que se ejecutan máquinas virtuales, y un almacenamiento compartido, donde se guardan los archivos de las máquinas virtuales. Si uno de los servidores falla, esas máquinas virtuales se restauran en otro servidor. Un clúster de conmutación por recuperación protege las máquinas virtuales sólo de fallos de hardware. La conmutación por recuperación es más costosa que la conmutación por réplica. Sin embargo, ofrece un tiempo de inactividad casi nulo, ya que las máquinas virtuales se encienden automáticamente en la ubicación secundaria cuando se produce un desastre.
¿Qué es la conmutación por error?
Una vez que haya recuperado su sitio primario después de un desastre y resuelto cualquier problema asociado, puede transferir las operaciones de negocio de nuevo a la máquina virtual de origen.
La conmutación por error ayuda a recuperar la máquina virtual original en el host de origen (o en una nueva ubicación de su elección) y a devolver las cargas de trabajo de la réplica de la máquina virtual a la máquina virtual original. Sin embargo, es posible que se hayan producido algunos cambios en la réplica de la máquina virtual desde la conmutación por error. Por lo tanto, la máquina virtual original y la réplica deben sincronizarse antes de realizar la conmutación por error para que no se pierda información crítica. En conmutación por error, sólo se devuelven al sistema original los datos modificados.
El proceso de conmutación por error y conmutación por recuperación como parte de la recuperación ante desastres.
Durante un evento de DR, se inician las operaciones de conmutación por error y conmutación por recuperación. El proceso se realiza del siguiente modo:
- La máquina virtual de origen en el sitio de producción se replica en el sitio de DR. Los datos de los discos virtuales de la réplica de la máquina virtual son idénticos a los datos del disco virtual de la máquina virtual de origen en el momento de la replicación. Si se produce un desastre (o si se prevé un desastre), se inicia la conmutación por recuperación a la réplica de la máquina virtual.
- Durante la conmutación por recuperación, las cargas de trabajo del sistema se transfieren al sitio de DR. Sin embargo, pueden producirse algunos cambios en la réplica VM a medida que continúan las operaciones. Es importante guardar estos datos porque el sistema original está desconectado y no registra ninguno de los cambios realizados. Así, todos los cambios se escriben únicamente en el disco virtual de la réplica de la máquina virtual.
- Una vez subsanadas las consecuencias negativas de una catástrofe (o pasada la posible amenaza), el sitio primario puede funcionar con normalidad. Así, se ejecuta la operación de conmutación por error; todas las cargas de trabajo se envían de vuelta desde la ubicación de DR al sitio de producción y los datos actualizados son recibidos por la VM de origen. La máquina virtual original y la réplica de la máquina virtual se sincronizan.
Prácticas recomendadas para la conmutación por error y la conmutación por recuperación en la recuperación ante desastres de máquinas virtuales
- Garantizar el cumplimiento de la normativa. Algunas organizaciones operan con datos muy sensibles y confidenciales, por lo que están obligadas a cumplir normativas como HIPAA o PCI DSS. Si este es su caso, debe comprobar si sus estrategias de RD para conmutación por error y recuperación cumplen las normas de seguridad aplicables.
- Compruebe las licencias. Revise la documentación de su software y determine si existen limitaciones de licencia en sus pilas de aplicaciones. Si es así, debe abordar cualquier problema de antemano y asegurarse de que se cumplen todos los requisitos.
- Defina el alcance de su plan de DR. El alcance de un plan de DR de máquinas virtuales determina qué sistemas deben protegerse e identifica los resultados esperados, así como las posibles limitaciones. Asegúrese de que su entorno virtual dispone de la capacidad técnica adecuada para cubrir todos los aspectos de su plan.
- Elija una solución de protección de datos fiable. Instalar una solución de protección de datos con la licencia adecuada en su entorno virtual es crucial para obtener un rendimiento eficiente y una integración perfecta. A efectos de planificación de la DR, debe establecer cuánto tarda el producto en recuperar su infraestructura virtual y restablecer todas las operaciones en el sitio de producción.
- Decidir quién es el responsable de la conmutación por error y la conmutación por recuperación. La dirección debe designar a los miembros de un equipo de recuperación y asignar responsabilidades específicas a cada uno de ellos. Determine quién es el responsable de la supervisión de las operaciones de conmutación por error y recuperación para evitar confusiones en un escenario de recuperación real cuando sea importante.
- Forme al personal informático en las operaciones de conmutación por error y recuperación. Siguiendo con el punto anterior, asegúrese de que su personal de TI cuenta con los conocimientos y cualificaciones necesarios para llevar a cabo operaciones de conmutación por error y failback. Los empleados responsables deben estar totalmente preparados por si algo no sale según lo previsto; deben tener un sólido conocimiento de las operaciones para poder adaptarse en consecuencia y hacer frente a cualquier problema que surja.
- Revisar los Acuerdos de Nivel de Servicio (SLA). Un acuerdo de nivel de servicio es un contrato entre un proveedor de servicios y sus clientes que determina los requisitos y estándares de servicio que se espera que cumpla el proveedor. Así pues, asegúrese de que sus acuerdos de nivel de servicio están actualizados y de que su aplicabilidad se extiende al entorno de RD.
- Definir RTOs y OPR. Un objetivo de tiempo de recuperación (RTO) es el periodo de tiempo durante el cual deben recuperarse las operaciones empresariales tras una catástrofe para evitar daños importantes y pérdidas críticas. El objetivo de punto de recuperación (RPO) significa la cantidad de datos (medida en tiempo) que pueden perderse sin causar niveles inaceptables de daño a su empresa. Un RPO es esencialmente el punto más lejano en el tiempo al que sus máquinas virtuales podrían ser revertidas en caso de desastre. Sus RTO y RPO deben establecerse principalmente en función de las prioridades de su organización durante un escenario de catástrofe. Aunque aumentar la frecuencia de los jobs de backup y replicación puede ser una tarea que consuma mucho tiempo y recursos, mejora considerablemente sus RPOs. Los RTO más cortos deben asignarse a los componentes de mayor prioridad, que deben recuperarse en primer lugar. Tenga en cuenta que los RTOs y RPOs deben establecerse para aplicaciones y VMs por separado.
- Considere la posibilidad de convertir su sitio de DR en un sitio permanente. Su empresa puede verse afectada por una catástrofe de grandes proporciones que haga imposible restaurar su centro de datos primario. Por lo tanto, considere la posibilidad de convertir su sitio de DR en un sitio permanente, de modo que pueda estar preparado de antemano para un evento de esta envergadura. Evidentemente, se trata de una solución cara que consume importantes cantidades de recursos y conlleva grandes costes de equipamiento, software e instalaciones. Puede ser beneficioso considerar lo que habría que hacer, aunque no sigas adelante con el plan inmediatamente.
- Pruebe las operaciones de conmutación por recuperación. Al probar su procedimiento de conmutación por recuperación, puede comprobar si su infraestructura virtual puede recuperarse correctamente en su sitio de DR y verificar que sus aplicaciones preinstaladas pueden ejecutarse correctamente incluso cuando su sitio de producción está desactivado.
- Pruebe las operaciones de conmutación por error. De este modo, podrá asegurarse de que las operaciones de su empresa pueden restaurarse con éxito desde el sitio de DR al sitio original.
- Pruebe su plan de RD en su totalidad. También merece la pena probar todo el plan de RD, ya que puede ayudar a identificar los puntos débiles del plan mediante la simulación de un evento de RD. Como resultado, podrá mejorar y adaptar las estrategias de RD aplicadas por su organización. Un plan de RD defectuoso y anticuado puede perturbar considerablemente la continuidad de la actividad de su organización.
Failover y Failback en NAKIVO Backup & Replication
NAKIVO Backup & Replication ofrece una exclusiva función Site Recovery, que permite crear flujos de trabajo de recuperación automatizados (o jobs) de cualquier complejidad. Los flujos de trabajo de restauración del entorno (SR) implican secuencias personalizadas de acciones, como failover, failback, iniciar/detener máquinas virtuales, ejecutar/detener jobs, conectar/desconectar repositorios, etc. Estas acciones pueden organizarse en cualquier orden para una automatización y orquestación totales del proceso de RD. Además, puede modificar, complementar o probar fácilmente sus job de SR en cualquier momento sin interrumpir el entorno de producción. De este modo, incluso el plan de DR más sofisticado puede crearse, probarse y luego aplicarse sin problemas con el uso de flujos de trabajo de SR.
Conmutación por recuperación ante desastres
La acción de conmutación por recuperación forma parte integrante de la mayoría de los flujos de trabajo de SR. La restauración del entorno mediante conmutación por error sólo puede ejecutarse si previamente se han creado réplicas de las máquinas virtuales de origen que se desea proteger; éstas se utilizan como objetivos para la conmutación por error cuando se produce un desastre. La carga de trabajo se transfiere de la máquina virtual de origen en el centro de producción afectado a una réplica de la máquina virtual en el centro de recuperación ante desastres.
NAKIVO Backup & Replication ha presentado tres tipos de failover:
- La conmutación por recuperación planificada se utiliza para la protección preventiva de sus sistemas cuando existe una amenaza potencial o si se espera un desastre. Si se le ha notificado la existencia de riesgos meteorológicos o si hay un corte de suministro eléctrico programado en la zona, puede iniciar una conmutación por recuperación planificada. En este caso, la solución sincroniza los datos entre la máquina virtual de origen y su réplica antes de transferir la carga de trabajo a la réplica; de este modo, se evita por completo la pérdida de datos.
- La conmutación por recuperación de prueba le ayuda a determinar si sus estrategias de conmutación por recuperación son funcionales y si se puede confiar en ellas en caso de que se produzca un evento de RD. La conmutación por recuperación de prueba se realiza de forma similar a la conmutación por recuperación planificada, con la salvedad de que todos los cambios realizados en modo de prueba se revierten inmediatamente para no causar interrupciones en el entorno primario. Además, puede probar si su flujo de trabajo se ejecuta con suficiente rapidez en un evento de RD. NAKIVO Backup & Replication le permite establecer un RTO para su job de restauración del entorno. Si el job tarda más del tiempo establecido en completarse, la prueba se considera fallida. Se envía un informe de prueba/ejecución por correo electrónico, que puede examinar para identificar deficiencias en su plan de RD y resolverlas.
- La conmutación por recuperación de emergencia se ejecuta inmediatamente después de que se produzca un desastre en su centro de producción y no se pueda acceder a la máquina virtual de origen. Con NAKIVO Backup & Replication, puede trasladar la carga de trabajo del sitio primario al sitio de DR en un solo clic. Así, se garantiza el mínimo tiempo de inactividad, aunque puedan perderse algunos datos.
Reprotección de máquinas virtuales en el sitio de DR
Una vez ejecutada la conmutación por recuperación, debe asegurarse de que las réplicas de máquinas virtuales que se ejecutan en su sitio de DR están protegidas. Las réplicas de máquinas virtuales también pueden dañarse, y si no hubiera otras copias, sería imposible recuperarlas inmediatamente.
Sin embargo, NAKIVO Backup & Replication garantiza que su infraestructura virtual vuelva a estar protegida tras un evento de DR. Simplemente replique las máquinas virtuales que se ejecutan en su sitio de DR a otra ubicación. De este modo, puede conmutar fácilmente a su nueva réplica de máquina virtual si ocurre algo inesperado. Puede configurar sus flujos de trabajo SR para iniciar automáticamente la replicación de las máquinas virtuales que se ejecutan en el sitio DR tan pronto como se complete la conmutación por recuperación, garantizando así altos niveles de protección.
Conmutación por error en la recuperación ante desastres
La conmutación por error sólo puede realizarse después de que se haya producido una conmutación por error en un flujo de trabajo SR. Transcurrido un tiempo, cuando su sitio principal vuelva a estar operativo, podrá reanudar las operaciones en la máquina virtual de origen. Para ello, puede volver a esta VM desde una réplica de VM que haya sustituido a la VM original. Si las cargas de trabajo de las máquinas virtuales no se pueden volver a transferir al sitio de producción principal (por ejemplo, porque no se puede restaurar), se pueden transferir a cualquier otra ubicación nueva de su elección para una solución a más largo plazo que el sitio de DR.
La conmutación por error puede ejecutarse en modo de producción o en modo de prueba.
- La conmutación por error en modo de prueba tiene por objeto determinar si el job SR puede ejecutarse correctamente, sin que surjan problemas durante el proceso real de conmutación por error. En este caso, la replicación incremental o completa desde la réplica de la máquina virtual a la máquina virtual de origen sólo se realiza una vez, lo que es suficiente para las pruebas. Asegúrese de que la dirección IP y los ajustes de red son correctos. La máquina virtual de origen y la réplica de la máquina virtual se sincronizan para evitar la pérdida de datos y, a continuación, se enciende la máquina virtual de origen. Tenga en cuenta que todos los cambios realizados en sus máquinas virtuales durante el proceso de conmutación por error se descartan una vez finalizada la prueba y su entorno virtual vuelve a su estado anterior a la conmutación por error. En el modo de prueba, se puede ejecutar un job de restauración del entorno a petición o programado.
- La conmutación por error en modo de producción se realiza cuando se desea recuperar el entorno de producción tras una conmutación por error de DR. En el modo de producción, un job de recuperación del entorno sólo puede ejecutarse bajo demanda. La conmutación por error en modo de producción sigue esencialmente los mismos pasos que la conmutación por error en modo de prueba. Sin embargo, la replicación de la réplica de la máquina virtual a la máquina virtual de origen se realiza dos veces para garantizar que no haya pérdida de datos en el proceso. Una vez completada la operación de replicación, la máquina virtual original (en el sitio de producción) se enciende y la réplica de la máquina virtual en el sitio de DR se apaga. (Tenga en cuenta que este último paso -apagado de las réplicas DR VM- sólo se produce en el modo de producción).
Conclusión
Comprender la tecnología que hay detrás de la conmutación por error y el failback e integrarla en su plan de recuperación ante desastres de máquinas virtuales puede proteger su entorno virtual de cualquier imprevisto. La conmutación por recuperación garantiza que los datos de misión crítica estén seguros y que todas las cargas de trabajo se transfieran rápidamente a un sitio de DR. La conmutación por error le permite volver del sitio de DR a su sitio de producción en unos pocos clics. Juntas, estas operaciones le ayudan a garantizar una pérdida de datos mínima y a reducir el tiempo de inactividad.
