<< Clic para mostrar Tabla de Contenidos >> Servicio de recuperación ante desastres |
Si desea aumentar la resiliencia de Automation Service y mantener la continuidad de los servicios bajo un escenario de interrupción o desastre, Bizagi ofrece el servicio de recuperación ante desastres. El servicio de recuperación ante desastres 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 Service.
Automation Service se aprovisiona un sitio primario cuya ubicación geográfica es escogida por usted de acuerdo con sus requerimientos (por ejemplo, para cumplir con regulaciones locales o preferencias de desempeño).
Al adquirir el servicio de recuperación ante desastres, Bizagi proporcionará un sitio secundario (llamado sitio de recuperación) que se utilizará en caso de que el sitio primario quede inoperativo debido a un desastre. El sitio de recuperación se aprovisiona geográficamente en lo que se conoce como una región emparejada y cuando sea posible, se encuentra al menos a 300 millas del sitio primario.
Este servicio está disponible solamente para el ambiente de producción de Automation Service. |
Tanto el sitio primario como el sitio de recuperación tienen una implementación completa. Esta implementación incluye Automation Service y una base de datos sincronizada.
El sitio de recuperación del réplica completa cubre todo el aprovisionamiento de la seguridad, el almacenamiento y otros recursos y configuraciones del sitio primario.
El sitio primario 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, las solicitudes de los usuarios se enrutan al sitio de recuperación.
Si tiene una VPN configurada, debe adquirir una segunda VPN (adicional). Esto 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 Automation Service después de una interrupción. El RTO es de 3 horas.
En caso de una interrupción importante, Bizagi declarará un desastre y activará el servicio de recuperación ante 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.
En esta opción 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, Automation Service 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. |
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 Automation Service después de una interrupción. El RTO es de 18 horas.
Escenario 1: Clientes con Recuperación de Desastres (DR) Adquirida
Para los clientes que han adquirido el servicio de Recuperación de Desastres (DR) de Bizagi, proporcionamos un nivel mejorado de protección y recuperación rápida en caso de desastre.
1.Respuesta Inmediata:
oDetección de Incidentes: Al detectar una interrupción del servicio, nuestros sistemas de monitoreo alertan a nuestro equipo de operaciones de DR inmediatamente.
oEvaluación: El equipo evalúa rápidamente la situación para confirmar el desastre y determinar el impacto en los servicios.
2.Notificación al Cliente:
oDeclaración de Desastre: Declaramos un desastre dentro de los 30 minutos a 1 hora después de la confirmación.
oComunicación: Los clientes son notificados vía correo electrónico dentro de las siguientes 4 horas, con actualizaciones y plazos estimados para la resolución.
3.Activación del Plan de DR:
oCambio a la Región Secundaria: Los servicios se cambian a una región de recuperación secundaria, asegurando un tiempo de inactividad mínimo.
oContinuidad del Servicio: Nuestro objetivo es cumplir con los Objetivos de Tiempo de Recuperación (RTO) y los Objetivos de Punto de Recuperación (RPO) especificados en el acuerdo de DR, asegurando una pérdida de datos mínima y una rápida restauración de los servicios.
4.Actualizaciones Continuas:
oInformes de Estado: Se proporcionan actualizaciones regulares a los clientes vía correo electrónico sobre el progreso de la recuperación y los tiempos de restauración esperados.
5.Post-Restauración:
oConfirmación: Los clientes son notificados tan pronto como los servicios estén completamente restaurados.
Escenario 2: Clientes Sin Recuperación de Desastres (Dependiendo de Alta Disponibilidad)
Para los clientes que no han optado por nuestro servicio de Recuperación de Desastres (DR), ofrecemos un Acuerdo de Nivel de Servicio (SLA) estándar con Alta Disponibilidad (HA) del 99.95%. Usted puede ampliar el porcentaje del SLA. Si consume más de 500 BPU mensuales tendrá un SLA del 99,99%. Si consume menos, puede adquirir un servicio de disponibilidad mejorada para aumentar su SLA al 99,99% pagando un costo adicional. Esto asegura la continuidad del negocio dentro de una única región de Azure. En el improbable caso de un desastre, nuestros procedimientos están diseñados para restaurar los servicios lo más rápidamente posible una vez que Azure haya resuelto el problema.
1.Respuesta Inicial:
oDetección de Incidentes: Nuestros sistemas de monitoreo alertan a nuestro equipo de operaciones ante cualquier interrupción del servicio.
oEvaluación: El equipo evalúa la situación para confirmar si es un desastre que afecta la región o centro de datos de Azure.
2.Notificación al Cliente:
oDeclaración de Desastre: Declaramos un desastre dentro de los 30 minutos a 1 hora después de la confirmación.
oComunicación: Los clientes son notificados vía correo electrónico dentro de las siguientes 6 horas, con actualizaciones y plazos estimados para la resolución.
3.Coordinación con Azure:
oMonitoreo: Trabajamos estrechamente con Azure para monitorear sus esfuerzos de restauración.
oRestauración del Servicio: Una vez que Azure restaura los servicios en la región afectada, nuestro equipo hace todo lo posible para restaurar nuestros servicios lo más rápido posible.
oComo no hay un Objetivo de Tiempo de Recuperación (RTO) o un Objetivo de Punto de Recuperación (RPO) definidos para los clientes sin DR, el tiempo de restauración dependerá del tiempo de resolución de Azure y los esfuerzos de recuperación subsiguientes de Bizagi.
oRestauración de Datos: Bizagi gestiona las copias de seguridad para minimizar las interrupciones en las operaciones normales, reducir el impacto general de interrupciones inesperadas del servicio y minimizar la pérdida de datos en caso de desastre. Las copias de seguridad son geo-replicadas. En caso de cualquier fallo, Bizagi puede restaurar la base de datos al punto de restauración más cercano basado en las copias de seguridad realizadas.
4.Post-Restauración:
oConfirmación de la Restauración del Servicio: Los clientes serán notificados tan pronto como los servicios estén completamente restaurados.
Resumen
Con DR Adquirido:
•Protección mejorada con una región de recuperación secundaria.
•Tiempo de inactividad mínimo con RTO y RPO específicos.
•Cambio rápido y actualizaciones continuas.
Sin DR (Alta Disponibilidad):
•Dependencia de la restauración de Azure.
•Sin RTO o RPO específicos.
•Esfuerzos para restaurar los servicios lo más rápido posible después de la recuperación de Azure.
Last Updated 11/29/2024 8:30:06 AM