Continuidad empresarial y recuperación ante desastres para el análisis a escala de la nube

  • Artículo

Al diseñar la arquitectura para un servicio en la nube, tenga en cuenta sus requisitos de disponibilidad y cómo dar respuesta a posibles interrupciones del servicio. Un problema puede estar localizado en una instancia concreta o abarcar a toda una región. Es importante disponer de planes para ambos escenarios. Según el objetivo de tiempo de recuperación y el objetivo de punto de recuperación, puede elegir una estrategia exigente para proporcionar alta disponibilidad y recuperación ante desastres.

A veces se pueden combinar la alta disponibilidad y la recuperación ante desastres. Las dos áreas tienen estrategias ligeramente diferentes, especialmente en lo que respecta a los datos. Para obtener más información, consulte el Marco de buena arquitectura de Microsoft Azure y sus principios de confiabilidad.

En lugar de intentar evitar errores, acepte por adelantado que los errores pueden producirse y se producen. Minimice los efectos que pueden provocar los errores de un único componente en el ciclo de vida. La tolerancia al costo, el objetivo de punto de recuperación y el objetivo de tiempo de recuperación determinan el tipo de solución que se debe implementar.

Estrategias de copia de seguridad

Existen muchas estrategias alternativas para implementar el proceso distribuido entre regiones. Estas se deben adaptar a los requisitos empresariales y a las circunstancias de la aplicación. En un nivel alto, los enfoques pueden dividirse en las siguientes categorías:

  • Copias de seguridad y restauración: restaure la aplicación de base de datos desde la última copia de seguridad antes del desastre. Este enfoque se usa normalmente si los datos han sufrido daños o se ha producido una eliminación accidental.

  • Volver a implementar en caso de desastre: : vuelva a implementar la aplicación desde cero en el momento del desastre. Este enfoque es adecuado para aplicaciones que no son críticas y no requieren un tiempo de recuperación garantizado.

  • Reserva semiactiva (activa/pasiva): cree un servicio hospedado secundario en una región alternativa. Implemente roles para garantizar una capacidad mínima. Los roles no reciben tráfico de producción. Este enfoque es útil para las aplicaciones que no se han diseñado para distribuir el tráfico entre las regiones.

  • Reserva activa (activa/activa): diseñe la aplicación para recibir la carga de producción en varias regiones. Podría configurar los servicios en la nube de cada región para una capacidad mayor de la necesaria para fines de recuperación ante desastres. En su lugar, se podrían escalar horizontalmente los servicios en la nube según sea necesario en el momento de un desastre y una conmutación por error.

    Este enfoque requiere una inversión en el diseño de la aplicación, pero tiene ventajas. Ofrece un tiempo de recuperación bajo y garantizado. Hay una comprobación continua de todas las ubicaciones de recuperación y un uso eficiente de la capacidad. Para las aplicaciones de base de datos, este enfoque incluye un equilibrador de carga para dos bases de datos que se sincronizan con un único punto de conexión.

Recuperación ante desastres y alta disponibilidad para servicios de Azure

En las secciones siguientes se abordan los distintos servicios de Azure.

Azure Cosmos DB

Para obtener información general sobre la alta disponibilidad con Azure Cosmos DB, consulte ¿Cómo proporciona Azure Cosmos DB la alta disponibilidad?.

Azure Data Factory

Es probable que las integraciones de datos y el producto de datos tengan repositorios de Azure DevOps vinculados a Azure Data Factory. Puede implementar canalizaciones en otra instancia de Data Factory con un tiempo de inactividad mínimo. Para usar software de control de versiones de código aparte del repositorio de Azure DevOps y GitHub, use el SDK de Azure Data Factory para crear canalizaciones y otros objetos de Azure Data Factory.

Azure Data Lake

Azure Data Lake Storage Gen2 ya admite la replicación 3x para proteger frente a los errores de hardware localizados. Otras opciones de replicación, como el almacenamiento con redundancia de zona (ZRS) o el almacenamiento con redundancia de zona geográfica (GZRS), mejoran la alta disponibilidad. El almacenamiento con redundancia geográfica (GRS) y el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) mejoran la recuperación ante desastres. Para una alta disponibilidad, si hay una interrupción del servicio, la carga de trabajo necesita acceder a los datos más recientes lo antes posible. La carga de trabajo puede cambiar a una instancia replicada localmente o a una nueva región.

Cualquier cuenta de almacenamiento configurada como RA-GRS o GRS puede formar parte de un plan de recuperación ante desastres, pero requiere la debida diligencia al analizar el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RPO), así como revisar otras opciones, como un escenario de carga dual que copia los datos en dos regiones de Azure diferentes.

Cada zona de aterrizaje de datos debe tener un objetivo de punto de recuperación para sus productos de datos. Cada zona de aterrizaje de datos debe tener una estrategia de replicación definida para sus casos de uso.

Nota:

La conmutación por error de la cuenta administrada por el cliente aún no es compatible con las cuentas que tienen un espacio de nombres jerárquico (Azure Data Lake Storage Gen2).

En caso de un desastre que afecte a la región principal, Microsoft administrará la conmutación por error para cuentas con un espacio de nombres jerárquico.

Para más información, consulte Recuperación ante desastres y conmutación por error de la cuenta de almacenamiento.

Azure Databricks

Para obtener información general sobre una arquitectura de recuperación ante desastres para clústeres de Azure Databricks, consulte Recuperación ante desastres regional para clústeres de Azure Databricks.

Azure Machine Learning

Para obtener información general sobre la alta disponibilidad con Azure Machine Learning, consulte Conmutación por error para la continuidad empresarial y la recuperación ante desastres.

Azure Key Vault

Azure Key Vault proporciona características para ayudarle a mantener la disponibilidad y evitar la pérdida de datos. Haga una copia de seguridad de los secretos solo si tiene una justificación empresarial crítica. La copia de seguridad de los secretos del almacén de claves puede plantear desafíos operativos adicionales, como el mantenimiento de varios conjuntos de registros, permisos y copias de seguridad cuando los secretos expiren o roten. Para obtener más información, consulte Copia de seguridad de Azure Key Vault.

Key Vault mantiene la disponibilidad en escenarios de desastre. Conmuta por error las solicitudes a una región emparejada sin la intervención de un usuario. Para más información, consulte Redundancia y disponibilidad de Azure Key Vault. Como alternativa, puede considerar la posibilidad de almacenar secretos y otros artefactos de Key Vault en un almacén secundario con los permisos adecuados. Este patrón puede ser adecuado para las aplicaciones que requieren que el almacén esté en la misma región que la aplicación.

Azure SQL Database

Para obtener información general sobre la continuidad empresarial con Azure SQL Database, consulte Introducción a la continuidad empresarial con Azure SQL Database.

Azure Synapse Analytics

Para obtener información general sobre la continuidad empresarial con Azure Synapse Analytics, consulte Alta disponibilidad para Azure Synapse Analytics.

Pasos siguientes