Guía de recuperación ante desastres específica de la experiencia

En este documento se proporcionan instrucciones específicas de la experiencia para recuperar los datos de Fabric en caso de un desastre regional.

Escenario de ejemplo

En muchas secciones de instrucciones de este documento se usa el siguiente escenario de ejemplo con fines de explicación e ilustración. Consulte este escenario según sea necesario.

Imagine que tiene una capacidad C1 en la región A que tiene un área de trabajo W1. Si ha activado la recuperación ante desastres para la capacidad C1, los datos de OneLake se replicarán en una copia de seguridad en la región B. Si la región A sufre interrupciones, el servicio Fabric de C1 conmuta por error a la región B.

Este escenario se ilustra en la imagen siguiente. En el cuadro de la izquierda se muestra la región interrumpida. En el cuadro central se representa la disponibilidad continua de los datos después de la conmutación por error y, en el cuadro de la derecha, se muestra la situación totalmente controlada después de que el cliente actúe para restaurar el funcionamiento completo de sus servicios.

Este es el plan de recuperación general:

1. Cree una capacidad C2 de Fabric en una nueva región.

2. Cree un área de trabajo W2 en C2, incluidos sus elementos correspondientes con los mismos nombres que en C1.W1.

3. Copie los datos de C1.W1 con interrupciones a C2.W2.

4. Siga las instrucciones dedicadas de cada componente para restaurar los elementos a su funcionamiento completo.

Este plan de recuperación supone que la región de origen del cliente permanece operativa. Si la región principal del inquilino experimenta una interrupción, los pasos descritos en este documento dependen de su recuperación, que Microsoft debe iniciar y completar primero.

Planes de recuperación específicos de la experiencia

En las secciones siguientes se proporcionan guías paso a paso para cada experiencia de Fabric a fin de ayudar a los clientes en el proceso de recuperación.

Ingeniería de datos

En esta guía se detallan los procedimientos de recuperación de la experiencia de ingeniería de datos. Abarca almacenes de lago, cuadernos y definiciones de trabajo de Spark.

Lakehouse

Los almacenes de lago de la región original siguen sin estar disponibles para los clientes. Para recuperar un almacén de lago, los clientes pueden volver a crearlo en el área de trabajo C2.W2. Se recomiendan dos enfoques para la recuperación de los almacenes de lago:

Enfoque 1: Uso del script personalizado para copiar tablas delta y archivos del almacén de lago

Los clientes pueden volver a crear los almacenes de lago mediante un script de Scala personalizado.

1. Cree el almacén de lago (por ejemplo, LH1) en el área de trabajo C2.W2 recién creada.

2. Cree un cuaderno en el área de trabajo C2.W2.

3. Para recuperar las tablas y los archivos del almacén de lago de datos original, consulte los datos con rutas de acceso de OneLake como abfss (consulte Conexión a Microsoft OneLake). Puede usar el siguiente ejemplo de código (consulte Introducción a las utilidades de Microsoft Spark) en el notebook para obtener las rutas ABFS de archivos y tablas del lakehouse original. (Reemplace C1.W1 con el nombre real del área de trabajo)

   mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Use el ejemplo de código siguiente para copiar tablas y archivos en el almacén de lago recién creado.

   1. En el caso de las tablas Delta, debe copiarlas de una en una para la recuperación en el nuevo almacén de lago. En el caso de los archivos del almacén de lago, puede copiar la estructura de archivos completa con todas las carpetas subyacentes con una sola ejecución.

   2. Póngase en contacto con el equipo de soporte técnico para obtener la marca de tiempo de la conmutación por error necesaria en el script.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Una vez ejecutado el script, las tablas aparecen en el nuevo lakehouse.

Enfoque 2: Uso del Explorador de Azure Storage para copiar archivos y tablas

Para recuperar solo archivos o tablas específicos del almacén de lago original, use el Explorador de Azure Storage. Consulta Integración de OneLake con el Explorador de Azure Storage para obtener los pasos detallados. Para tamaños de datos grandes, use Enfoque 1.

Notebook

Los cuadernos de la región primaria siguen sin estar disponibles para los clientes y el código de los cuadernos no se replica en la región secundaria. Hay dos enfoques para recuperar el código del cuaderno en la nueva región.

Enfoque 1: Redundancia administrada por el usuario con integración de Git (en versión preliminar pública)

La mejor manera de facilitar y agilizar este proceso consiste en usar la integración de Git con Fabric y, después, sincronizar el cuaderno con el repositorio de ADO. Una vez que el servicio conmuta por error a otra región, puede usar el repositorio para recompilar el cuaderno en el área de trabajo que ha creado.

1. Configure la integración de Git para su área de trabajo y seleccione Conectar y sincronizar con el repositorio de ADO.

   

   En la imagen siguiente se muestra el cuaderno sincronizado.

   

2. Recupere el cuaderno del repositorio de ADO.

   1. En el área de trabajo recién creada, vuelva a conectarse al repositorio de Azure ADO.

      

   2. Seleccione el botón Control de código fuente. Después, seleccione la rama correspondiente del repositorio. Luego, seleccione Actualizar todo. Aparece el bloc de notas original.

      

      

   3. Si el cuaderno original tiene un almacén de lago predeterminado, los usuarios pueden hacer referencia a la sección Almacén de lago para recuperarlo y, después, conectar el almacén de lago recién recuperado al cuaderno recién recuperado.

      

   4. La integración de Git no admite la sincronización de archivos, carpetas ni instantáneas de cuadernos en el explorador de recursos del cuaderno.

      1. Si el cuaderno original tiene archivos en el explorador de recursos del cuaderno:

         1. Asegúrese de guardar los archivos o carpetas en un disco local u otro lugar.

         2. Vuelva a cargar el archivo desde el disco local o las unidades en la nube en el cuaderno recuperado.

      2. Si el cuaderno original tiene una instantánea de cuaderno, guárdela también en su propio sistema de control de versiones o en el disco local.

         

         

Para más información sobre la integración de Git, vea Introducción a la integración de Git.

Enfoque 2: Enfoque manual para realizar copias de seguridad del contenido de código

Si no adopta el enfoque de integración de Git, puede guardar la versión más reciente del código, los archivos en el explorador de recursos y la instantánea del cuaderno en un sistema de control de versiones, como Git, y recuperar manualmente el contenido del cuaderno después de un desastre:

1. Use la característica "Importar cuaderno" para importar el código del cuaderno que quiera recuperar.

   

2. Después de la importación, vaya al área de trabajo deseada (por ejemplo, "C2.W2") para acceder a ella.

3. Si el cuaderno original tiene un almacén de lago predeterminado, consulte la sección Almacén de lago. Después, conecte el almacén de lago recién recuperado (que tiene el mismo contenido que el almacén de lago predeterminado original) al cuaderno recién recuperado.

4. Si el cuaderno original tiene archivos o carpetas en el explorador de recursos, vuelva a cargar los archivos o carpetas guardados en el sistema de control de versiones del usuario.

Definición de trabajos de Spark

Las definiciones de trabajos de Spark (SJD) de la región primaria siguen sin estar disponibles para los clientes, y el archivo de definición principal y el archivo de referencia del cuaderno se replicarán en la región secundaria mediante OneLake. Si quiere recuperar la SJD en la nueva región, puede seguir los pasos manuales que se describen a continuación para hacerlo. Los registros históricos del SJD no se recuperarán.

Para recuperar los elementos de SJD, copie el código de la región original mediante el Explorador de Azure Storage y vuelva a conectar manualmente las referencias de almacén de lago después del desastre.

1. Cree un elemento de SJD (por ejemplo, SJD1) en el nuevo área de trabajo C2.W2, con los mismos valores y configuraciones que el elemento de SJD original (por ejemplo, idioma, entorno, etc.).

2. Use el Explorador de Azure Storage para copiar archivos de biblioteca, archivos principales e instantáneas del elemento de SJD original al nuevo elemento de SJD.

   

3. El contenido del código aparecerá en la SJD recién creada. Tendrá que agregar manualmente al trabajo la referencia de almacén de lago recién recuperada (consulte los pasos de recuperación de almacenes de lago). Los usuarios tendrán que volver a escribir manualmente los argumentos de la línea de comandos originales.

   

Ahora puede ejecutar o programar la SJD recién recuperada.

Para más información sobre el Explorador de Azure Storage, vea Integración de OneLake con el Explorador de Azure Storage.

Ciencia de datos

En esta guía se detallan los procedimientos de recuperación de la experiencia de ciencia de datos. Se describen modelos y experimentos de ML.

Modelo y experimento de ML

Los elementos de ciencia de datos de la región primaria siguen sin estar disponibles para los clientes, y el contenido y los metadatos de los modelos y experimentos de ML no se replicarán en la región secundaria. Para recuperarlos completamente en la nueva región, guarde el contenido del código en un sistema de control de versiones (como Git) y vuelva a ejecutar manualmente el contenido del código después del desastre.

1. Recupere el cuaderno. Consulte los pasos de recuperación de cuadernos.

2. La configuración, las métricas de ejecución histórica y los metadatos no se replicarán en la región emparejada. Tendrá que volver a ejecutar cada versión del código de ciencia de datos para recuperar completamente los modelos y experimentos de ML después del desastre.

Data Warehouse

En esta guía se detallan los procedimientos de recuperación de la experiencia de almacenamiento de datos. Se describen los almacenes de datos.

Warehouse

Los almacenes de la región original siguen sin estar disponibles para los clientes. Para recuperar los almacenes, siga estos dos pasos.

1. Cree un almacén de lago provisional en el área de trabajo C2.W2 para los datos que copiará del almacén original.

2. Rellene las tablas Delta del almacén con el Explorador de almacenamiento y las funcionalidades de T-SQL (vea Tablas en el almacenamiento de datos en Microsoft Fabric).

Ingesta de datos mediante almacenes de lago y código de T-SQL

En el área de trabajo C2.W2 recién creada:

1. Cree un almacén de lago provisional "LH2" en C2.W2.

2. Siga los pasos de recuperación de almacenes de lago para recuperar las tablas Delta en el almacén de lago provisional del original.

3. Cree un almacén "WH2" en C2.W2.

4. Conecte el almacén de lago provisional en el explorador de almacenamiento.

5. En función de cómo vaya a implementar las definiciones de tabla antes de la importación de datos, el T-SQL real que se usa para las importaciones puede variar. Puede usar el enfoque INSERT INTO, SELECT INTO o CREATE TABLE AS SELECT para recuperar las tablas de almacenamiento de los almacenes de lago. Más adelante en el ejemplo, se usará el tipo INSERT INTO. (Si usa el código siguiente, reemplace los ejemplos por nombres reales de tabla y columna)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Por último, cambie la cadena de conexión en las aplicaciones mediante el almacenamiento de Fabric.

Base de datos reflejada

Las bases de datos reflejadas de la región primaria siguen sin estar disponibles para los clientes y la configuración no se replica en la región secundaria. Para recuperarla en caso de error regional, debe volver a crear la base de datos reflejada en otra área de trabajo desde otra región.

Data Factory

Los elementos de Data Factory de la región primaria siguen sin estar disponibles para los clientes, y los ajustes y la configuración en las canalizaciones o elementos de flujo de datos Gen2 no se replicarán en la región secundaria. Para recuperar estos elementos en caso de un error regional, deberá volver a crear los elementos de integración de datos en otra área de trabajo desde otra región. En las secciones siguientes se describen los detalles.

Flujos de datos Gen2

Si quiere recuperar un elemento de Flujo de datos Gen2 en la nueva región, debe exportar un archivo PQT a un sistema de control de versiones como Git y, luego, recuperar manualmente el contenido de Flujo de datos Gen2 después del desastre.

1. Para el elemento Flujo de datos Gen2, en la pestaña Inicio del editor de Power Query, seleccione Exportar plantilla.

   

2. En el cuadro de diálogo Exportar plantilla, escriba un nombre (obligatorio) y una descripción (opcional) para esta plantilla. Cuando termine, seleccione Aceptar.

   

3. Después del desastre, cree un elemento Flujo de datos Gen2 en el nuevo área de trabajo "C2.W2".

4. En el panel de vista actual del editor Power Query, seleccione Importar desde una plantilla de Power Query.

   

5. En el cuadro de diálogo Abrir, vaya a la carpeta Descargas predeterminada y seleccione el archivo .pqt que ha guardado en los pasos anteriores. A continuación, seleccione Abrir.

6. Después, la plantilla se importa al nuevo elemento Flujo de datos Gen2.

La función "Guardar como" de los flujos de datos no está disponible en situaciones de recuperación ante desastres.

Tuberías

Los clientes no pueden acceder a canalizaciones en caso de desastre regional y las configuraciones no se replican en la región emparejada. Recomendamos construir sus canalizaciones críticas en varios espacios de trabajo en distintas regiones.

Copiar trabajo

Los usuarios de CopyJob deben adoptar medidas proactivas para protegerse frente a un desastre regional. El siguiente enfoque garantiza que, después de un desastre regional, los CopyJobs de un usuario permanecen disponibles.

Redundancia administrada por el usuario con la integración de Git (en versión preliminar pública)

La mejor manera de facilitar y agilizar este proceso es usar la integración de Git de Fabric y, a continuación, sincronizar copyJob con el repositorio de ADO. Una vez que el servicio se traslade a otra región, puede usar el repositorio para recompilar el CopyJob en el nuevo área de trabajo que creó.

1. Configure la integración de Git del área de trabajo y seleccione conectar y sincronizar con el repositorio de ADO.

   

   En la siguiente imagen se muestra el CopyJob sincronizado.

   

2. Recupere copyJob del repositorio de ADO.

   1. En el área de trabajo recién creada, vuelva a conectar y sincronizar con el repositorio de Azure ADO. Todos los elementos de Fabric de este repositorio se descargan automáticamente en el nuevo área de trabajo.

      

   2. Si el copyJob original usa una instancia de Lakehouse, los usuarios pueden hacer referencia a la sección Lakehouse para recuperar Lakehouse y, a continuación, conectar el copyJob recién recuperado a la instancia de Lakehouse recién recuperada.

Para más información sobre la integración de Git, vea Introducción a la integración de Git.

Trabajo de Apache Airflow

Los usuarios de Apache Airflow Job in Fabric deben adoptar medidas proactivas para protegerse frente a un desastre regional.

Se recomienda administrar la redundancia con la integración de Git de Fabric. En primer lugar, sincronice el trabajo de Flujo de aire con el repositorio de ADO. Si el servicio conmuta por error a otra región, puede usar el repositorio para recompilar el trabajo de Flujo de aire en la nueva área de trabajo que creó.

Estos son los pasos para lograrlo:

1. Configure la integración de Git del área de trabajo y seleccione "conectar y sincronizar" con el repositorio de ADO.

2. Después, verá que el trabajo de Airflow se ha sincronizado con el repositorio de ADO.

3. Si necesita recuperar el trabajo de Airflow desde el repositorio de ADO, vuelva a crear un área de trabajo, conéctese y sincronice con el repositorio de Azure ADO. Todos los elementos de Fabric, incluido Airflow, en este repositorio se descargarán automáticamente en la nueva área de trabajo.

Inteligencia en tiempo real

En esta guía se detallan los procedimientos de recuperación de la experiencia de inteligencia en tiempo real. Se describen bases de datos o conjuntos de consultas KQL y secuencias de eventos.

Conjunto de consultas o base de datos KQL

Los usuarios de bases de datos o conjuntos de consultas KQL deben adoptar medidas proactivas para protegerse frente a un desastre regional. El siguiente enfoque garantiza que, en caso de desastre regional, los datos de los conjuntos de consultas y bases de datos KQL permanecen seguros y accesibles.

Siga estos pasos para garantizar una solución de recuperación ante desastres eficaz para bases de datos y conjuntos de consultas de KQL.

1. Establecer bases de datos KQL independientes: configure dos o más bases de datos KQL o conjuntos de consultas independientes en las capacidades dedicadas de Fabric. Se deben configurar en dos regiones de Azure diferentes (preferiblemente regiones emparejadas con Azure) para maximizar la resistencia.

2. Replicar actividades de administración: cualquier acción de administración realizada en una base de datos de KQL se debe reflejar en la otra. Esto garantiza que ambas bases de datos permanezcan sincronizadas. Entre las actividades clave que se van a replicar se incluyen las siguientes:

   • Tablas: asegúrese de que las estructuras de tabla y las definiciones de esquema sean coherentes entre las bases de datos.

   • Asignación: duplique las asignaciones necesarias. Asegúrese de que los orígenes de datos y los destinos se alinean correctamente.

   • Directivas: asegúrese de que ambas bases de datos tengan directivas similares de retención de datos, de acceso y demás directivas pertinentes.

3. Administrar la autenticación y la autorización: para cada réplica, configure los permisos necesarios. Asegúrese de que se establecen los niveles de autorización adecuados y de conceder acceso al personal necesario al tiempo que mantiene los estándares de seguridad.

4. Ingesta de datos paralelos: para mantener los datos coherentes y listos en varias regiones, cargue el mismo conjunto de datos en cada base de datos KQL al mismo tiempo que la ingiere.

Eventstream

Una secuencia de eventos es un lugar centralizado en la plataforma Fabric para capturar, transformar y enrutar eventos en tiempo real a varios destinos (por ejemplo, almacenes de lago, bases de datos o conjuntos de consultas de KQL) con una experiencia sin código. Siempre que los destinos sean compatibles con la recuperación ante desastres, las secuencias de eventos no perderán datos. Por tanto, los clientes deben usar las funcionalidades de recuperación ante desastres de esos sistemas de destino para garantizar la disponibilidad de los datos.

Los clientes también pueden lograr redundancia geográfica mediante la implementación de cargas de trabajo de Eventstream idénticas en varias regiones de Azure como parte de una estrategia activa/activa de varios sitios. Con un enfoque activo/activo de varios sitios, los clientes pueden acceder a su carga de trabajo en cualquiera de las regiones implementadas. Este enfoque es el más complejo y costoso para la recuperación ante desastres, pero puede reducir el tiempo de recuperación a casi cero en la mayoría de las situaciones. Para obtener una redundancia geográfica completa, los clientes pueden

1. Crear réplicas de sus orígenes de datos en regiones diferentes.

2. Cree elementos Eventstream en las regiones correspondientes.

3. Conectar estos nuevos elementos a los orígenes de datos idénticos.

4. Agregar destinos idénticos para cada secuencia de eventos en regiones diferentes.

Base de datos transaccional

En esta guía se describen los procedimientos de recuperación para la experiencia de base de datos transaccional.

SQL database

Para protegerse frente a un error regional, los usuarios de bases de datos SQL pueden tomar medidas proactivas para exportar periódicamente sus datos y usar los datos exportados para volver a crear la base de datos en una nueva área de trabajo cuando sea necesario.

Esto se puede lograr mediante la herramienta de la CLI de SqlPackage que proporciona portabilidad de base de datos y facilita las implementaciones de bases de datos.

1. Use la herramienta SqlPackage para exportar la base de datos a un .bacpac archivo. Consulte Exportación de una base de datos con SqlPackage para obtener más información.
2. Almacene el .bacpac archivo en una ubicación segura que se encuentra en una región diferente de la base de datos. Algunos ejemplos incluyen almacenar el .bacpac archivo en una instancia de Lakehouse que se encuentra en otra región, mediante una cuenta de Azure Storage con redundancia geográfica o mediante otro medio de almacenamiento seguro que se encuentra en una región diferente.
3. Si la base de datos SQL y la región no están disponibles, puede usar el .bacpac archivo con SqlPackage para volver a crear la base de datos en un área de trabajo en una nueva región: área de trabajo C2. W2 en la región B, tal como se describe en el escenario anterior. Siga los pasos que se detallan en Importación de una base de datos con SqlPackage para volver a crear la base de datos con el .bacpac archivo.

La base de datos recreada es una base de datos independiente de la base de datos original y refleja el estado de los datos en el momento de la operación de exportación.

Consideraciones de conmutación por recuperación

La base de datos recreada es una base de datos independiente. Los datos agregados a la base de datos recreada no se reflejarán en la base de datos original. Si tiene previsto realizar la conmutación por recuperación a la base de datos original cuando la región principal esté disponible, deberá considerar la posibilidad de reconciliar manualmente los datos de la base de datos recreada en la base de datos original.

Platform

La plataforma hace referencia a los servicios compartidos y la arquitectura subyacentes que se aplican a todas las cargas de trabajo. Esta sección le guía por los procedimientos de recuperación para experiencias compartidas. Trata las bibliotecas de variables.

Biblioteca de variables

Las bibliotecas de variables de Microsoft Fabric permiten a los desarrolladores personalizar y compartir configuraciones de elementos dentro de un área de trabajo, lo que simplifica la administración del ciclo de vida del contenido. Desde el punto de vista de la recuperación ante desastres, los usuarios de la biblioteca de variables deben protegerse proactivamente frente a un desastre regional. Esto se puede hacer a través de la integración de Git de Fabric, lo que garantiza que después de un desastre regional, la biblioteca de variables de un usuario permanece disponible. Para recuperar una biblioteca de variables, se recomienda lo siguiente:

• Use la integración de Git de Fabric para sincronizar la biblioteca de variables con el repositorio de ADO. En caso de desastre, puede usar el repositorio para volver a generar la biblioteca de variables en el nuevo área de trabajo que ha creado. Siga estos pasos:

  1. Conecte el área de trabajo al repositorio de Git como se describe aquí.
  2. Asegúrese de mantener el WS y el repositorio sincronizados con confirmación y actualización.
  3. Recuperación: en caso de desastre, use el repositorio para volver a generar la biblioteca de variables en una nueva área de trabajo:

• En el área de trabajo recién creada, vuelva a conectar y sincronizar con el repositorio de Azure ADO.

• Todos los elementos de Fabric de este repositorio se descargan automáticamente en el nuevo área de trabajo.

• Después de sincronizar los elementos desde Git, abra las bibliotecas de variables en el nuevo área de trabajo y seleccione manualmente el conjunto de valores activos deseado.

Claves administradas por el cliente para áreas de trabajo de Fabric

Puede usar claves administradas por el cliente (CMK) almacenadas en Azure Key Vault para agregar una capa adicional de cifrado sobre las claves administradas por Microsoft para los datos en reposo. En caso de que Fabric sea inaccesible o inoperable en una región, sus componentes migrarán a una instancia de copia de seguridad. Durante la conmutación por error, la característica CMK admite operaciones de solo lectura. Mientras el servicio Azure Key Vault siga funcionando correctamente y los permisos de la bóveda estén intactos, Fabric continuará conectándose a su clave criptográfica y permitirá la lectura normal de datos. Esto significa que no se admiten las siguientes operaciones durante la conmutación por error: habilitar y deshabilitar la configuración de CMK del área de trabajo y actualizar la clave.

Información relacionada

• Guía de recuperación ante desastres de Microsoft Fabric