Definición del caso de uso
Para incluir este ejemplo de trabajo, se usará la firma ficticia "Contoso" con una plataforma de datos de Azure basada en las arquitecturas de referencia de Microsoft.
Servicio de datos: vista de componentes
Contoso ha implementado la siguiente arquitectura básica de Azure, que es un subconjunto del diseño de zona de aterrizaje empresarial.
Los números de las descripciones siguientes se corresponden a los del diagrama anterior.
Fundamentos de Azure de Contoso: flujo de trabajo
- Inscripción empresarial: la inscripción empresarial principal de Contoso dentro de Azure que refleja su contrato comercial con Microsoft, su estructura de cuentas organizativas y las suscripciones de Azure disponibles. Proporciona la base de facturación de las suscripciones y cómo se administra el patrimonio digital.
- Administración de identidades y acceso : los componentes necesarios para proporcionar servicios de identidad, autenticación, acceso a recursos y autorización en el patrimonio de Azure de Contoso.
- Organización de grupos de administración y suscripción : una jerarquía de grupos escalable alineada con las funcionalidades principales de la plataforma de datos, lo que permite la operacionalización a escala mediante la seguridad y gobernanza administradas centralmente donde las cargas de trabajo tienen una separación clara. Los grupos de administración de Azure proporcionan un ámbito de gobernanza por encima de las suscripciones.
- Suscripción de administración: una suscripción dedicada para las distintas funciones de nivel de administración de necesarias para admitir la plataforma de datos.
- Suscripción de conectividad: una suscripción dedicada para las funciones de conectividad de la plataforma de datos que le permiten identificar servicios con nombre, determinar el enrutamiento seguro y la comunicación entre los servicios internos y externos.
- Suscripción de zona de aterrizaje: suscripciones de uno a varios para aplicaciones nativas, en línea de Azure, cargas de trabajo y recursos internos y externos
- Plataforma de DevOps: la plataforma de DevOps que admite todo el patrimonio de Azure. Esta plataforma contiene el repositorio de control de código fuente base y las canalizaciones de CI/CD que permiten implementaciones automatizadas de infraestructura como código (IaC).
Nota:
Muchos clientes aún conservan una gran huella de infraestructura como servicio (IaaS). Para proporcionar funcionalidades de recuperación en IaaS, el componente clave que se va a agregar es Azure Site Recovery. Site Recovery orquestará y automatizará la replicación de máquinas virtuales de Azure entre regiones, de máquinas virtuales locales y de servidores físicos en Azure, así como de máquinas locales en un centro de datos secundario.
En el marco de esta estructura fundacional, Contoso ha implementado los siguientes elementos para dar soporte a sus necesidades de inteligencia empresarial, de acuerdo con las instrucciones de Analytics de un extremo a otro con Azure Synapse.
Plataforma de datos de Contoso
Plataforma de datos de Contoso: flujo de trabajo
El flujo de trabajo se lee de izquierda a derecha, siguiendo el flujo de datos:
- Orígenes de datos: orígenes o tipos de datos de los que puede consumir la plataforma de datos.
- Ingesta: funcionalidad de la plataforma para ingerir (procesar) datos de diversos orígenes de estructura y velocidad variables. Este diseño refleja una arquitectura lambda.
- Store : la capacidad de almacenar datos de forma segura a escala que se han ingerido en la plataforma.
- Proceso: funcionalidad de la plataforma para procesar datos, haciendo que sean "aptos según los objetivos" para los procesos finales, como la limpieza, la estandarización y el modelado. El preprocesamiento de los datos normalmente garantiza que se encuentra en una "posición y una condición, lista para su uso".
- Enriquecimiento : la capacidad de mejorar los datos procesados en la plataforma a través de técnicas estadísticas, de aprendizaje automático u otras técnicas de modelado o de servicios precompilados de Azure AI.
- Serve : la capacidad de la plataforma para dar forma y presentar datos para el consumo de bajada.
- Consumidores de datos: los usuarios, las aplicaciones o los procesos de bajada que consumen datos de los distintos puntos de contacto de servicio de las plataformas.
- Detectar y controlar : las funcionalidades de la plataforma para controlar los datos que contiene y asegurarse de que se indexan, detectan o buscan, se describen correctamente, con linaje completo y son transparentes para sus usuarios finales y los procesos que consumen.
- Plataforma : la base sobre la que se compila la plataforma, es decir, las bases de Azure de Contoso, como se ha descrito anteriormente.
Nota:
Para muchos clientes, el nivel conceptual de la arquitectura de referencia de la plataforma de datos usada estará alineado, pero la implementación física puede variar. Por ejemplo, los procesos ELT (extracción, carga, transformación) se pueden realizar mediante Azure Data Factory y el modelado de datos mediante un servidor de Azure SQL. Para solucionar este problema, la sección Componentes con estado frente a sin estado a continuación proporcionará instrucciones.
Para la plataforma de datos, Contoso ha seleccionado los niveles de servicio de producción recomendados más bajos para todos los componentes y ha elegido adoptar una estrategia de recuperación ante desastres (DR) "Reimplementación ante desastres" basada en un enfoque de reducción de costos operativos.
Las secciones siguientes proporcionarán una comprensión de línea base del proceso de recuperación ante desastres y las palancas disponibles para que los clientes mejoren esta postura.
Vista de componentes y servicios de Azure
En las tablas siguientes, se presenta un desglose de cada servicio y componente de Azure que se usa en la plataforma de datos de Contoso, con opciones para mejorar la recuperación ante desastres.
Nota:
Las secciones siguientes están organizadas por servicios con estado frente a sin estado.
Componentes fundamentales con estado
Microsoft Entra ID, incluyendo los derechos de roles
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: Premium P1
- Opciones de elevación de recuperación ante desastres: la resistencia de Microsoft Entra forma parte de su oferta de software como servicio (SaaS).
- Notas
Azure Key Vault
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Almacén de Recovery Services
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: valor predeterminado (almacenamiento con redundancia geográfica (GRS))
- Opciones de elevación de recuperación ante desastres: al habilitar la restauración entre regiones se crea la restauración de datos en la región secundaria emparejada.
- Notas
- Aunque el almacenamiento con redundancia local (LRS) y el almacenamiento con redundancia de zona (ZRS) están disponibles, requiere actividades de configuración de la configuración predeterminada.
Azure DevOps
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: DevOps Services
- Opciones de elevación de recuperación ante desastres: el servicio DevOps y la resistencia de datos forman parte de su oferta de SaaS.
- Notas
- DevOps Server como oferta local seguirá siendo responsabilidad del cliente para la recuperación ante desastres.
- Si se usan servicios de terceros (SonarCloud, Jfrog Artifactory, servidores de compilación de Jenkins, por ejemplo), seguirán siendo responsabilidad del cliente la recuperación de un desastre.
- Si las máquinas virtuales de IaaS se usan en la cadena de herramientas de DevOps, seguirán siendo responsabilidad del cliente la recuperación de un desastre.
Componentes fundamentales sin estado
Suscripciones
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Grupos de administración
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Azure Monitor
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Cost Management
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Microsoft Defender for Cloud
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
DNS de Azure
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: zona única pública
- Opciones de elevación de recuperación ante desastres: N/A, DNS es de alta disponibilidad por diseño.
Network Watcher
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Redes virtuales, incluidas subredes, rutas definidas por el usuario (UDR) y grupos de seguridad de red (NSG)
- Responsabilidad de recuperación de componentes: Contoso
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: las redes virtuales se pueden replicar en la región secundaria emparejada.
Azure Firewall
- Responsabilidad de recuperación de componentes: Contoso
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres: Azure Firewall es de alta disponibilidad por diseño y se puede crear con Availability Zones para aumentar la disponibilidad.
Azure DDoS
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: protección de red contra DDoS
- Opciones de elevación de recuperación ante desastres: N/A, cubierto como parte del servicio de Azure.
Circuito de ExpressRoute
- Responsabilidad de recuperación de componentes: Contoso, asociado de conectividad y Microsoft
- Responsabilidad de recuperación de la carga de trabajo y configuración: asociado de conectividad y Microsoft
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres:
- ExpressRoute se puede elevar para usar el emparejamiento privado, lo que proporciona un servicio con redundancia geográfica.
- ExpressRoute también tiene diseños de alta disponibilidad (HA) disponibles.
- La conexión VPN de sitio a sitio se puede usar como copia de seguridad de ExpressRoute.
- Notas
- ExpressRoute tiene redundancia integrada, con cada circuito que consta de dos conexiones a dos enrutadores perimetrales (MSE) de Microsoft Enterprise en una ubicación de ExpressRoute desde el perímetro de red del proveedor o cliente de conectividad.
- El circuito Premium de ExpressRoute habilitará el acceso a todas las regiones de Azure globalmente.
VPN Gateway
- Responsabilidad de recuperación de componentes: Contoso
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: zona única (VpnGw1)
- Opciones de elevación de recuperación ante desastres: una puerta de enlace de VPN se puede implementar en una zona de disponibilidad con las SKU vpnGw#AZ para proporcionar un servicio con redundancia de zona.
Equilibrador de carga de Azure
- Responsabilidad de recuperación de componentes: Contoso
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres:
- Se puede configurar un equilibrador de carga para la redundancia de zona dentro de una región con zonas de disponibilidad. Si es así, la ruta de acceso de datos sobrevivirá siempre que una zona dentro de la región siga siendo correcta.
- En función de la región primaria, se puede implementar un equilibrador de carga entre regiones para una implementación de alta disponibilidad entre regiones.
- Notas
- Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS. Este servicio admite la distribución del tráfico de las aplicaciones de acceso público en las regiones globales de Azure. Esta solución proporcionará protección contra una interrupción regional dentro de un diseño de alta disponibilidad.
Servicios específicos de la plataforma de datos con estado
Cuenta de almacenamiento: Azure Data Lake Gen2
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: LRS
- Opciones de elevación de recuperación ante desastres: las cuentas de almacenamiento tienen una amplia gama de opciones de redundancia de datos desde la redundancia de región primaria hasta la redundancia de región secundaria.
- Notas
- Se recomienda GRS para aumentar la redundancia, proporcionando una copia de los datos en la región emparejada.
Azure Event Hubs
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres: se puede crear un espacio de nombres del centro de eventos con zonas de disponibilidad habilitadas . Esta resistencia se puede ampliar para cubrir una interrupción completa de la región con la recuperación ante desastres geográfica.
- Notas
- Por diseño, la recuperación ante desastres geográfica de Event Hubs no replica los datos, por lo que hay varias consideraciones que se deben tener en cuenta para la conmutación por error y la reserva.
Instancias de Azure IoT Hub
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres:
- La resistencia de IoT Hub se puede elevar mediante una implementación de alta disponibilidad entre regiones.
- Microsoft proporciona las siguientes instrucciones para las opciones de alta disponibilidad y recuperación ante desastres.
- Notas
- IoT Hub proporciona conmutación por error iniciada por Microsoft y conmutación por error manual mediante la replicación de datos en la región emparejada para cada centro de IoT.
- IoT Hub proporciona alta disponibilidad dentro de la región y usará automáticamente una zona de disponibilidad si se crea en un conjunto predefinido de regiones de Azure.
Azure Stream Analytics
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Estándar
- Opciones de elevación de recuperación ante desastres: aunque Azure Stream Analytics es una oferta de plataforma como servicio (PaaS) totalmente administrada, no proporciona conmutación automática por error geográfica. La redundancia geográfica se puede lograr mediante la implementación de trabajos idénticos de Stream Analytics en varias regiones de Azure.
Azure Machine Learning
- Responsabilidad de recuperación de componentes: Contoso y Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: De uso general, instancias de la serie D
- Opciones de elevación de recuperación ante desastres:
- Azure Machine Learning depende de varios servicios de Azure, algunos de los cuales se aprovisionan en la suscripción del cliente. Por lo tanto, el cliente sigue siendo responsable de la configuración de alta disponibilidad de estos servicios.
- La resistencia se puede elevar a través de una implementación multir regional.
- Notas:
- Azure Machine Learning no proporciona conmutación automática por error ni recuperación ante desastres.
Power BI
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: Power BI Pro
- Opciones de elevación de recuperación ante desastres: N/A, la resistencia de Power BI forma parte de su oferta de SaaS.
- Notas
- Power BI reside en el inquilino de Office365, no en el de Azure.
- Power BI usa Azure Availability Zones para proteger informes, aplicaciones y datos de Power BI frente a errores del centro de datos.
- En caso de error regional, Power BI conmutará por error a una nueva región, normalmente en la misma ubicación geográfica, como se indica en el Centro de confianza de Microsoft.
Azure Cosmos DB
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: escritura en una sola región con copia de seguridad periódica
- Opciones de elevación de recuperación ante desastres:
- Las cuentas de una sola región pueden perder disponibilidad después de una interrupción regional. La resistencia se puede elevar a una sola región de escritura y al menos una segunda región (lectura) y habilitar la conmutación por error administrada por el servicio.
- Se recomienda que las cuentas de Azure Cosmos DB utilizadas para las cargas de trabajo de producción tengan habilitada la conmutación por error automática. En ausencia de esta configuración, la cuenta experimentará la pérdida de la disponibilidad de escritura durante todo el tiempo que dure la interrupción de la región de escritura, ya que la conmutación por error manual no se realizará correctamente debido a la falta de conectividad con la región.
- Notas
- Para protegerse contra la pérdida de datos en una región, Azure Cosmos DB proporciona dos modos de copia de seguridad diferentes periódicos y continuos - .
- El cliente de Azure Cosmos DB detecta y controla las conmutaciones por error regionales. No requieren ningún cambio de la aplicación.
- En las instrucciones siguientes se describe el impacto de una interrupción de una región en función de la configuración de Cosmos DB.
Azure Data Share
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: la implementación de alta disponibilidad en una región secundaria puede aumentar la resistencia de Azure Data Share.
Microsoft Purview
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: N/A
- Opciones de elevación de recuperación ante desastres: N/A
- Notas
- A partir de octubre de 2024, Microsoft Purview no admite la continuidad empresarial automatizada y la recuperación ante desastres (BCDR). Hasta que se agregue esa compatibilidad, el cliente es responsable de todas las actividades de copia de seguridad y restauración.
Servicios específicos de la plataforma de datos sin estado
Azure Synapse: canalizaciones
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Gen2 optimizado para proceso
- Opciones de elevación de recuperación ante desastres: la resistencia de N/A y Synapse forma parte de su oferta de SaaS mediante la característica de conmutación automática por error.
- Notas
- Si se usan canalizaciones de datos autohospedados, seguirán siendo responsabilidad del cliente la recuperación de un desastre.
Azure Synapse: grupos de Data Explorer
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: optimizado para proceso, pequeño (4 núcleos)
- Opciones de elevación de recuperación ante desastres: la resistencia de N/A y Synapse forma parte de su oferta de SaaS.
- Notas
- Availability Zones está habilitado de manera predeterminada para Synapse Data Explorer cuando esté disponible.
Azure Synapse: grupos de Spark
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: optimizado para proceso, pequeño (4 núcleos)
- Opciones de elevación de recuperación ante desastres: la resistencia de N/A y Synapse forma parte de su oferta de SaaS.
- Notas
- Actualmente, Azure Synapse Analytics solo admite la recuperación ante desastres para grupos de SQL dedicados y no lo admite para grupos de Apache Spark.
Azure Synapse: grupos de SQL dedicados y sin servidor
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Contoso
- Selección de SKU de Contoso: Gen2 optimizado para proceso
- Opciones de elevación de recuperación ante desastres: la resistencia de N/A y Synapse forma parte de su oferta de SaaS.
- Notas
- Azure Synapse Analytics toma automáticamente instantáneas durante todo el día para crear puntos de restauración disponibles durante siete días.
- Azure Synapse Analytics lleva a cabo una copia de seguridad geográfica estándar una vez al día en un centro de datos emparejado. El objetivo de punto de recuperación (RPO) de una restauración geográfica es de 24 horas.
- Si se usan canalizaciones de datos autohospedados, seguirán siendo responsabilidad de los clientes la recuperación de un desastre.
Servicios de Azure AI (previamente Cognitive Services)
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: Pago por uso
- Opciones de elevación de recuperación ante desastres: N/A, las API para los servicios de inteligencia artificial se hospedan en centros de datos administrados por Microsoft.
- Notas
Azure AI Search (anteriormente Cognitive Search)
- Responsabilidad de recuperación de componentes: Microsoft
- Responsabilidad de recuperación de carga de trabajo y configuración: Microsoft
- Selección de SKU de Contoso: Estándar S1
- Opciones de elevación de recuperación ante desastres:
- La búsqueda de IA se puede generar en un diseño de alta disponibilidad mediante réplicas entre zonas de disponibilidad y regiones.
- Varios servicios de regiones independientes pueden ampliar aún más la resistencia.
- Notas
- En la Búsqueda de AI, la continuidad empresarial (y la recuperación ante desastres) se logra mediante varios servicios de la Búsqueda de AI.
- No hay ningún mecanismo integrado para la recuperación ante desastres. Si se requiere un servicio continuo durante un error catastrófico, se recomienda tener un segundo servicio en otra región e implementar una estrategia de replicación geográfica para garantizar que los índices sean totalmente redundantes en todos los servicios.
Componentes con estado frente a sin estado
La velocidad de innovación en el conjunto de productos de Microsoft y Azure, en particular, significa que el conjunto de componentes que hemos usado para este ejemplo de trabajo evolucionará rápidamente. Para evitar que las orientaciones queden obsoletas en el futuro y ampliarlas a componentes no cubiertos explícitamente en este documento, la sección siguiente proporciona algunas instrucciones basadas en la clasificación general del estado.
Un componente o servicio se puede describir como con estado si está diseñado para recordar eventos anteriores o interacciones del usuario. Sin estado significa que no hay ningún registro de las interacciones anteriores y cada solicitud de interacción se debe controlar completamente en función de la información que viene con ella.
Para un escenario de recuperación ante desastres que se basa en una nueva implementación:
- Los componentes o servicios que no tienen estado, como Azure Functions y las canalizaciones de Azure Data Factory, se pueden volver a implementar desde el control de código fuente con al menos una prueba de humo para validar la disponibilidad antes de introducirse en el sistema más amplio.
- Los componentes o servicios que son "con estado", como Azure SQL Database y las cuentas de almacenamiento, requieren más atención.
- Al proteger el componente, una decisión clave será la selección de la característica de redundancia de datos. Esta decisión se centra normalmente en un equilibrio entre disponibilidad y durabilidad con los costos operativos.
- Los almacenes de datos también necesitarán una estrategia de copia de seguridad de datos. La funcionalidad de redundancia de datos del almacenamiento subyacente mitiga este riesgo para algunos diseños, mientras que otras, como las bases de datos SQL, necesitarán un proceso de copia de seguridad independiente.
- Si es necesario, el componente se puede volver a implementar desde el control de código fuente con una configuración validada a través de una prueba de humo.
- Un almacén de datos redistribuido debe tener su conjunto de datos rehidratado. La rehidratación se puede lograr mediante la redundancia de datos (cuando esté disponible) o un conjunto de datos de copia de seguridad. Cuando se haya completado la rehidratación, debe validarse para obtener precisión e integridad.
- En función de la naturaleza del proceso de copia de seguridad, los conjuntos de datos de copia de seguridad pueden requerir validación antes de aplicarse. Los errores o daños en el proceso de copia de seguridad pueden dar lugar a que se use una copia de seguridad anterior en lugar de la versión más reciente disponible.
- Cualquier diferencia entre la fecha y la marca de tiempo del componente y la fecha actual deben abordarse reexecutando o reproduciendo los procesos de ingesta de datos desde ese punto hacia adelante.
- Una vez actualizado el conjunto de datos del componente, se puede introducir en el sistema más amplio.
Otros servicios clave
Esta sección contiene instrucciones de alta disponibilidad y recuperación ante desastres para otros servicios y componentes clave de datos de Azure.
- Azure Databricks: puede encontrar instrucciones de recuperación ante desastres en la documentación del producto.
- Las instrucciones de alta disponibilidad de Azure Analysis Services se pueden encontrar en la documentación del producto.
- Azure Database for MySQL
- SQL
Pasos siguientes
Ahora que ha aprendido sobre la arquitectura del escenario, puede obtener información sobre los detalles del escenario.
Recursos relacionados
- Recuperación ante desastres para la plataforma de datos de Azure: información general
- Recuperación ante desastres en la plataforma de datos de Azure: detalles del escenario
- Recuperación ante desastres para una plataforma de datos de Azure: recomendaciones
- Recuperación ante desastres en una plataforma de datos de Azure: implementación de este escenario