Introducción
Bizagi confía en el SLA predeterminado de Azure de 99.95%. Si desea aumentar este valor y mantener la continuidad de los servicios bajo un escenario de interrupción o desastre, Bizagi ofrece servicios de recuperación ante desastres (DR). El servicio DR ofrece dos opciones: replicar la base de datos o el conjunto completo de recursos. Este servicio tiene un costo adicional a las tarifas del servicio de Automation.
|
Este servicio está disponible solamente para el ambiente de producción. |
Solo base de datos
En la opción con recuperación de desastres, el entorno está completamente implementado en la región primaria. Ambos sitios están sincronizados con el contenido de la base de datos. En caso de desastre, el servicio de automatización se activa en un sitio secundario y se conecta a la base de datos en espera. Todas las solicitudes se enrutan al nuevo sitio utilizando la base de datos replicada. Con este enfoque, no es necesario incurrir en gastos generales y el tiempo que requiere la operación de restauración de la base de datos porque la base de datos está lista y ejecutándose.
Objetivo de punto de recuperación de la Base de Datos (RPO)
Este es el punto donde se recuperan los datos de la base de datos. En esta opción de recuperación de desastres con solo base de datos el RPO es de 5 minutos.
Objetivo de punto de recuperación de los archivos (RPO)
Este es el punto donde se recuperan los datos correspondientes a los archivos adjuntos en casos. En esta opción de recuperación de desastres con solo base de datos, el RPO es de menos 15 minutos para los archivos, y es diferente del RPO de la base de datos porque los archivos son almacenados en un Storage Account.
|
Es importante entender la diferencia entre la base de datos, y el almacenamiento de archivos. La base de datos contiene la información en tablas relacionales, mientras que los archivos, para mejorar el performance, se almacenan en un Storage Account. Ver Arquitectura de Automation Service. |
Réplica completa
Tanto el sitio primario como el sitio de recuperación tienen una implementación completa. Esta implementación incluye los servicios de Automation y una base de datos sincronizada. El sitio principal maneja activamente las solicitudes de la interacción de los usuarios finales. El sitio de recuperación se activa solo cuando el sitio primario experimenta una interrupción del servicio y se ha declarado un desastre. En ese caso, todas las solicitudes de nuevos usuarios se enrutan al sitio de recuperación.
|
Si tiene una VPN, debe comprar una segunda VPN (adicional). Esta segunda VPN se configura en el onboarding. |
Este enfoque proporciona un RTO más bajo. La conmutación por error ocurre más rápido porque la aplicación y los servicios ya están implementados. Este servicio tiene las siguientes características:
Objetivo de punto de recuperación de la Base de Datos (RPO)
Este es el punto donde se recuperan los datos de la base de datos. En esta opción de recuperación de desastres completa el RPO es de 5 minutos.
Objetivo de punto de recuperación de los archivos (RPO)
Este es el punto donde se recuperan los datos correspondientes a los archivos adjuntos en casos. En esta opción de recuperación de desastres completa el RPO es de menos 15 minutos para los archivos, y es diferente del RPO de la base de datos porque los archivos son almacenados en un Storage Account.
|
Es importante entender la diferencia entre la base de datos, y el almacenamiento de archivos. La base de datos contiene la información en tablas relacionales, mientras que los archivos, para mejorar el performance, se almacenan en un Storage Account. Ver Arquitectura de Automation Service. |
Objetivo de tiempo de recuperación del ambiente (RTO)
Este es el período de tiempo en el que se restaura todo su servicio de Automatización de Bizagi después de una interrupción. El RTO es de 6 horas.
En caso de una interrupción importante, Bizagi declarará un desastre y activará el plan de recuperación de desastres. Como resultado, el sitio de recuperación se activará temporalmente y recibirá la operación de manera segura, aislada y confiable. El sitio de recuperación será redirigido a la base de datos replicada. Después de que se haya resuelto el evento de Desastre, Bizagi tomará la decisión de iniciar el plan alternativo para ejecutar el servicio en el sitio primario original. Durante la conmutación por error, los usuarios pueden experimentar un ligero impacto en el rendimiento, pero es temporal ya que el sitio de recuperación se ejecutará en el mismo nivel de rendimiento del sitio primario.