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 varias 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.

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 original, debe usar la ruta de acceso de ABFS para acceder a los datos (vea Conexión a Microsoft OneLake). Puede usar el ejemplo de código siguiente (vea Introducción a las utilidades de Microsoft Spark) del cuaderno para obtener las rutas de acceso de ABFS de archivos y tablas del almacén de lago 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 que ejecute el script, las tablas aparecerán en el nuevo almacén de lago.

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.

Nota:

Los dos enfoques descritos anteriormente recuperan los metadatos y los datos de las tablas con formato Delta, ya que los metadatos están colocados y almacenados con los datos de OneLake. En el caso de las tablas con un formato distinto a Delta (por ejemplo, CSV, Parquet, etc.) que se crean mediante scripts o comandos del lenguaje de definición de datos (DDL) de Spark, el usuario es responsable de mantener y volver a ejecutar los comandos o scripts DDL de Spark para recuperarlos.

Notebook

Los cuadernos de la región primaria siguen sin estar disponibles para los clientes y el código de los cuadernos no se replicará 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 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. Aparecerá el cuaderno 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. Tenga en cuenta que las ejecuciones históricas de la 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).

Nota:

Se recomienda mantener el código de almacenamiento (esquema, tabla, vista, procedimiento almacenado, definiciones de función y códigos de seguridad) con versiones y guardarlo en una ubicación segura (como Git) según los procedimientos de desarrollo.

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.

Nota:

Para los clientes que necesitan recuperación ante desastres entre regiones y continuidad empresarial totalmente automatizada, se recomienda mantener dos configuraciones de almacenamiento de Fabric en regiones de Fabric independientes y mantener la paridad de código y datos mediante implementaciones periódicas e ingesta de datos en ambos sitios.

Data Factory

Los elementos de Data Factory de la región primaria siguen sin estar disponibles para los clientes y los valores y la configuración en canalizaciones de datos 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.

Dataflows 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.

Canalizaciones de datos

Los clientes no pueden acceder a canalizaciones de datos en caso de desastre regional y las configuraciones no se replican en la región emparejada. Se recomienda crear las canalizaciones de datos críticas en varias áreas de trabajo en distintas regiones.

Real-Time Analytics

En esta guía se detallan los procedimientos de recuperación de la experiencia de análisis 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.

Información relacionada

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