Рекомендации по аварийному восстановлению, адаптированные к конкретным сценариям использования

В этом документе содержатся рекомендации, основанные на практическом опыте, по восстановлению данных Fabric в случае региональной катастрофы.

Пример сценария

Многие разделы руководства в этом документе используют следующий пример сценария для объяснения и иллюстрации. При необходимости обратитесь к этому сценарию.

Предположим, что у вас есть емкость C1 в регионе A с рабочей областью W1. Если вы включили аварийное восстановление для емкости C1, данные OneLake реплицируются в резервную копию в регионе B. Если регион A сталкивается с нарушениями, служба Fabric в C1 осуществляет переключение на регион B.

Этот сценарий показан на следующем рисунке. В поле слева отображается нарушенный регион. Блок в середине представляет постоянную доступность данных после отработки отказа, а блок справа показывает полностью покрытую ситуацию после того, как клиент предпринимает действия по восстановлению служб до полной функциональности.

Ниже приведен общий план восстановления:

1. Создайте новую емкость Fabric C2 в новом регионе.

2. Создайте новую рабочую область W2 в C2, включая соответствующие элементы с теми же именами, что и в C1. W1.

3. Скопируйте данные из сбойного C1.W1 в C2.W2.

4. Следуйте выделенным инструкциям для каждого компонента, чтобы восстановить элементы до полной функции.

Этот план восстановления предполагает, что домашний регион клиента остается рабочим. Если в домашнем регионе клиента возникает сбой, шаги, описанные в этом документе, зависят от его восстановления, которые должны быть сначала инициированы и завершены Microsoft.

Планы восстановления, специфичные для опыта

В следующих разделах приведены пошаговые руководства по каждому интерфейсу Fabric, помогающие клиентам в процессе восстановления.

Инжиниринг данных

В этом руководстве описаны процедуры восстановления для интерфейса Инжиниринг данных. В ней рассматриваются архитектуры lakehouse, записные книжки и определения заданий Spark.

Лэйкхаус

Дома у озера из исходного региона остаются недоступными для заказчиков. Чтобы восстановить lakehouse (озерохранилище), клиенты могут повторно создать его в рабочей области C2.W2. Мы рекомендуем два подхода для восстановления лейкхаусов:

Подход 1. Использование пользовательского скрипта для копирования таблиц и файлов Delta Lakehouse

Клиенты могут воссоздать lakehouses, используя пользовательский скрипт на Scala.

1. Создайте lakehouse (например, LH1) в недавно созданной рабочей области C2.W2.

2. Создайте записную книжку в рабочей области C2. W2.

3. Чтобы восстановить таблицы и файлы из исходного lakehouse, обратитесь к данным с путями OneLake, такими как abfss (см. Connecting to Microsoft OneLake). В следующем примере кода (см. раздел Введение в служебные программы Microsoft Spark) в блокноте, чтобы получить пути ABFS файлов и таблиц из исходного озера-хранилища данных. (Замените C1. W1 с фактическим именем рабочей области)

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

4. Используйте следующий пример кода для копирования таблиц и файлов в недавно созданный lakehouse.

   1. Для таблиц Delta необходимо скопировать таблицу по одному за раз, чтобы восстановиться в новом лейкхаусе. В случае файлов Lakehouse можно скопировать полную структуру файлов со всеми базовыми папками с одним выполнением.

   2. Обратитесь в службу поддержки, чтобы получить метку времени для переключения на резервную систему, необходимую в скрипте.

   %%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
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. После запуска скрипта таблицы отображаются в новом lakehouse.

Подход 2. Использование Azure Storage Explorer для копирования файлов и таблиц

Чтобы восстановить только определенные файлы или таблицы Lakehouse из оригинального Lakehouse, используйте Azure Storage Explorer. Подробные инструкции см. в статье Integrate OneLake с помощью Azure Storage Explorer. Для больших размеров данных используйте подход 1.

Восстановление Fabric материализованных представлений озера

Материализованные представления Lake из исходного региона остаются недоступными для клиентов после отработки отказа. Расписания обновления и история выполнения не реплицируются в вторичный регион. Чтобы восстановить их, выполните следующие действия после восстановления данных Lakehouse.

• Восстановите таблицы Lakehouse с помощью метода 1 или подхода 2, описанного выше. Скопируйте только исходные таблицы.
• Восстановите записные книжки, содержащие определения MLV. Обратитесь к разделу "Ноутбук" для действий по восстановлению.
• Запустите восстановленные записные книжки для повторного создания MLV в новом Lakehouse. Сведения о создании материализованных представлений озера см. в разделе Создание материализованного представления озера. Если на предыдущем шаге также были скопированы MLVs, выполните команду CREATE OR REPLACE в процессе их воссоздания.
• Повторно создайте расписания обновления MLV вручную в новой рабочей области. Журнал расписания и метрики выполнения не восстанавливаются.
• Если ваши MLVs используются для наполнения семантических моделей или отчетов, проверьте и обновите ссылки на идентификатор Lakehouse и идентификатор набора данных при необходимости. Повторно подключите отчеты к обновленной семантической модели и проверьте свежесть данных.

Записная книжка

Записные книжки из основного региона остаются недоступными для клиентов, а код в записных книжках не реплицируется в дополнительный регион. Чтобы восстановить код записной книжки в новом регионе, существует два подхода к восстановлению содержимого кода записной книжки.

Подход 1. Избыточность, управляемая пользователем, с интеграцией Git (в общедоступной предварительной версии)

Лучший способ сделать это легко и быстро — использовать интеграцию с Fabric Git, а затем синхронизировать вашу записную книжку с репозиторием Azure DevOps. После переключения службы на другой регион можно использовать репозиторий для перестроения записной книжки в новой рабочей области, которую вы создали.

1. Настройте интеграцию Git для вашей рабочей среды и выберите Подключиться и синхронизировать с репозиторием ADO.

   

   На следующем рисунке показана синхронизированная записная книжка.

   

2. Восстановите записную книжку из репозитория ADO.

   1. В созданной рабочей области снова подключитесь к репозиторию ADO Azure.

      

   2. Выберите кнопку управления версиями. Затем выберите соответствующую ветвь репозитория. Затем нажмите кнопку "Обновить все". Появится исходная записная книжка.

      

      

   3. Если исходная записная книжка имеет озеро по умолчанию, пользователи могут обратиться к разделу Lakehouse, чтобы восстановить озеро, а затем подключить только что восстановленный lakehouse к вновь восстановленной записной книжке.

      

   4. Интеграция Git не поддерживает синхронизацию файлов, папок или моментальных снимков записных книжек в обозревателе ресурсов записной книжки.

      1. Если исходная записная книжка содержит файлы в обозревателе ресурсов записной книжки:

         1. Не забудьте сохранить файлы или папки на локальный диск или в другом месте.

         2. Повторно отправьте файл с локального диска или облачных дисков в восстановленную записную книжку.

      2. Если в исходной записной книжке есть моментальный снимок записной книжки, сохраните моментальный снимок записной книжки в собственной системе управления версиями или локальном диске.

         

         

Дополнительные сведения об интеграции с Git см. в статье "Введение в интеграцию с Git".

Подход 2. Ручной подход к резервному копированию содержимого кода

Если вы не используете подход к интеграции с Git, вы можете сохранить последнюю версию кода, файлы в обозревателе ресурсов и моментальный снимок записной книжки в системе управления версиями, например Git, и вручную восстановить содержимое записной книжки после аварии:

1. Используйте функцию импорта записной книжки для импорта кода записной книжки, который требуется восстановить.

   

2. После импорта перейдите в нужную рабочую область (например, "C2". W2") для доступа к нему.

3. Если исходная записная книжка имеет озеро по умолчанию, обратитесь к разделу Lakehouse. Затем подключите вновь восстановленный lakehouse (с тем же содержимым, что и оригинальный lakehouse по умолчанию) к восстановленной записной книжке.

4. Если исходная записная книжка содержит файлы или папки в обозревателе ресурсов, повторно отправьте файлы или папки, сохраненные в системе управления версиями пользователя.

Определение задания Spark

Определения заданий Spark (SJD) из основного региона остаются недоступными для клиентов, а основной файл определения и файл ссылок в записной книжке будут реплицированы в дополнительный регион через OneLake. Если вы хотите восстановить SJD в новом регионе, выполните описанные ниже действия, чтобы восстановить SJD. Исторические запуски SJD не будут восстановлены.

Чтобы восстановить элементы SJD, скопируйте код из исходного региона с помощью Azure Storage Explorer и вручную переподключите ссылки Lakehouse после аварии.

1. Создайте новый элемент SJD (например, SJD1) в новой рабочей области C2. W2 с теми же параметрами и конфигурациями, что и исходный элемент SJD (например, язык, среда и т. д.).

2. Используйте Azure Storage Explorer для копирования Libs, Mains и моментальных снимков из исходного элемента SJD в новый элемент SJD.

   

3. Содержимое кода появится в только что созданном SJD. Вам потребуется вручную добавить ссылку на только что восстановленный Lakehouse в задание (см. инструкции по восстановлению Lakehouse). Пользователям потребуется повторно ввести исходные аргументы командной строки вручную.

   

Теперь вы можете запустить или запланировать только что восстановленный SJD.

Дополнительные сведения об Azure Storage Explorer см. в разделе Интеграция OneLake с Azure Storage Explorer.

Обработка и анализ данных

В этом руководстве описаны процедуры восстановления для опыта использования Data Science. В нем рассматриваются модели машинного обучения и эксперименты.

Модель машинного обучения и эксперимент

Элементы науки о данных из основного региона остаются недоступными для клиентов, а содержимое и метаданные в моделях машинного обучения и экспериментах не будут реплицироваться во вторичный регион. Чтобы полностью восстановить их в новом регионе, сохраните содержимое кода в системе управления версиями (например, Git) и повторно запустите содержимое кода после аварии.

1. Восстановите записную книжку. Ознакомьтесь с инструкциями по восстановлению записной книжки.

2. Конфигурация, исторические метрики и метаданные не будут копироваться в парный регион. Вам придется повторно запустить каждую версию кода для обработки и анализа данных, чтобы полностью восстановить модели машинного обучения и эксперименты после аварии.

Хранилище данных

В этом руководстве описаны процедуры восстановления для интерфейса Data Warehouse. Он охватывает склады.

Склад

Склады из исходного региона остаются недоступными для клиентов. Чтобы восстановить склады, выполните следующие два шага.

1. Создайте промежуточное озеро в рабочей области C2. W2 для данных, которые будут скопированы из исходного хранилища.

2. Заполните таблицы Delta хранилища, используя Warehouse Explorer и возможности T-SQL (см. Таблицы в хранилище данных в Microsoft Fabric).

Прием данных с помощью кода Lakehouse и T-SQL

В созданной рабочей области C2. W2:

1. Создайте промежуточный озерный дом "LH2" в C2. W2.

2. Восстановите таблицы Delta в промежуточном lakehouse из исходного хранилища данных, выполнив шаги по восстановлению Lakehouse.

3. Создайте хранилище "WH2" в C2. W2.

4. Подключите промежуточное озеро в обозревателе хранилища.

5. В зависимости от способа развертывания определений таблиц перед импортом данных фактический T-SQL, используемый для импорта, может отличаться. Вы можете использовать метод INSERT INTO, SELECT INTO или CREATE TABLE AS SELECT для восстановления таблиц хранилища из lakehouses. Далее в примере мы будем использовать в качестве варианта INSERT INTO. (Если вы используете приведенный ниже код, замените примеры фактическими именами таблиц и столбцов)

   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. Наконец, измените connection string в приложениях, использующих хранилище Fabric.

Зеркальная база данных

Зеркальные базы данных из первичного региона остаются недоступными для клиентов, и настройки не реплицируются во вторичный регион. Чтобы восстановить его в случае регионального сбоя, необходимо повторно создать зеркальную базу данных в другой рабочей области из другого региона.

Фабрика данных

Элементы фабрики данных из основного региона остаются недоступными для клиентов, а параметры и конфигурация в конвейерах или элементах потока данных 2-го поколения не будут реплицироваться в дополнительный регион. Чтобы восстановить эти элементы в случае регионального сбоя, необходимо повторно создать элементы Интеграция данных в другой рабочей области из другого региона. В следующих разделах описаны сведения.

Потоки данных 2-го поколения

Если вы хотите восстановить элемент потока данных 2-го поколения в новом регионе, необходимо экспортировать PQT-файл в систему управления версиями, например Git, а затем вручную восстановить содержимое потока данных 2-го поколения после аварии.

1. В элементе Dataflow 2-го поколения на вкладке "Главная" в редакторе Power Query выберите Экспорт шаблона.

   

2. В диалоговом окне "Экспорт шаблона" введите имя (обязательно) и описание (необязательно) для этого шаблона. При готовности выберите ОК.

   

3. После аварии создайте элемент потока данных второго поколения в новой рабочей области «C2.W2».

4. В текущей области представления редактора Power Query выберите Import из шаблона Power Query.

   

5. В диалоговом окне "Открыть" перейдите к папке загрузки по умолчанию и выберите PQT-файл , сохраненный на предыдущих шагах. Щелкните Открыть.

6. Затем шаблон импортируется в новый элемент потока данных 2-го поколения.

Функция потоков данных 'Сохранить как' не поддерживается в случае восстановления после аварии.

Трубопроводы

Клиенты не могут получить доступ к конвейерам в случае региональной аварии, а конфигурации не реплицируются в парный регион. Рекомендуется создавать критически важные конвейеры в нескольких рабочих областях в разных регионах.

Создать копию задания

Пользователи CopyJob должны предпринять упреждающие меры для защиты от региональной катастрофы. Данный подход гарантирует, что копии заданий пользователя остаются доступными после региональной катастрофы.

Избыточность, управляемая пользователем, с интеграцией Git (в общедоступной предварительной версии)

Лучший способ упростить этот процесс и быстро — использовать интеграцию Fabric Git, а затем синхронизировать copyJob с репозиторием ADO. После перехода службы на другой регион, можно использовать репозиторий для перестройки задания CopyJob в созданной вами рабочей области.

1. Настройте интеграцию Git рабочей области и выберите подключиться и синхронизировать с репозиторием ADO.

   

   На следующем рисунке показан синхронизированный файл CopyJob.

   

2. Восстановите файл CopyJob из репозитория ADO.

   1. В созданной рабочей области снова подключитесь к репозиторию Azure ADO и синхронизируйте их. Все элементы Fabric в этом репозитории автоматически скачиваются в новое рабочее пространство.

      

   2. Если исходный CopyJob использует Lakehouse, пользователи могут ссылаться на раздел Lakehouse для восстановления Lakehouse, а затем подключить только что восстановленный CopyJob к вновь восстановленному Lakehouse.

Дополнительные сведения об интеграции с Git см. в статье "Введение в интеграцию с Git".

Задание Apache Airflow

Пользователи задания Apache Airflow в Fabric должны предпринять упреждающие меры для защиты от региональной катастрофы.

Мы рекомендуем управлять избыточностью с помощью интеграции Fabric Git. Сначала синхронизируйте задание Airflow с репозиторием ADO. Если служба переключается на другой регион, можно использовать репозиторий для перестроения задачи Airflow в созданной рабочей области.

Ниже приведены шаги по достижению этого:

1. Настройте интеграцию Git рабочей области и выберите "Подключиться и синхронизировать" с репозиторием ADO.

2. После этого вы увидите, что задание Airflow синхронизировано с репозиторием ADO.

3. Если необходимо восстановить задание Airflow из репозитория ADO, создайте новую рабочую область, подключитесь и снова синхронизируйте его с репозиторием ADO Azure. Все элементы Fabric, в том числе Airflow, из этого репозитория будут автоматически загружены в вашу новую рабочую область.

Аналитика в режиме реального времени

В этом руководстве описаны процедуры восстановления для пользовательского опыта с системой Аналитики в режиме реального времени. В нем рассматриваются базы данных KQL, наборы запросов и потоки событий.

Модель графа или набор запросов

Элементы модели графов и набора запросов к графу из основного региона остаются недоступными для клиентов, и эти элементы не реплицируются во вторичный регион. Чтобы восстановить, создайте или используйте ресурс в другом регионе и воссоздайте там элементы модели Graph и набора запросов Graph.

1. Создайте или используйте существующую мощность Fabric в другом регионе, на который не влияет авария.

2. Создайте новую рабочую область или используйте существующую в этой роли.

3. Повторно создайте элемент модели Graph во вторичной рабочей области, как указано в шаге 2. Перенастройка определения модели, включая узлы, края и т. д., чтобы соответствовать исходной модели Graph.

4. Если исходный лейкхаус находится в неработоемом регионе, сначала восстановите его, следуя разделу Lakehouse.

5. Подключите Lakehouse в качестве источника данных OneLake для недавно созданного элемента графовой модели. Используйте восстановленное озерохранилище, если оно было в неработающем регионе, или повторно подключитесь к существующему озерохранилищу, если оно остается доступным.

6. Перенастройка расписаний загрузки данных или подключений для модели Graph в новой рабочей области.

7. Повторно создайте элемент набора запросов Graph в вторичной рабочей области. Повторно внесите запросы и все сохраненные конфигурации запросов из исходного набора запросов Graph.

База данных/набор запросов KQL

Пользователи базы данных и набора запросов KQL должны предпринять упреждающие меры для защиты от региональной катастрофы. Следующий подход гарантирует, что в случае региональной аварии данные в наборах запросов к базам данных KQL остаются безопасными и доступными.

Чтобы гарантировать эффективное решение аварийного восстановления для баз данных и наборов запросов KQL, выполните следующие действия.

1. Создайте независимые базы данных KQL: настройте две или более независимые базы данных или наборы запросов KQL на выделенных платформах Fabric. Они должны быть настроены в двух разных регионах Azure (предпочтительно парные регионы Azure), для максимальной устойчивости.

2. Репликация действий управления: все действия управления, выполненные в одной базе данных KQL, должны быть зеркально отражены в другой. Это гарантирует, что обе базы данных остаются в синхронизации. Ключевые действия для репликации включают:

   • Таблицы. Убедитесь, что структуры таблиц и определения схемы согласованы между базами данных.

   • Сопоставление: дублируются все необходимые сопоставления. Убедитесь, что источники данных и пункты назначения правильно выровнены.

   • Политики. Убедитесь, что обе базы данных имеют аналогичные политики хранения, доступа и других соответствующих политик.

3. Управление проверкой подлинности и авторизацией. Для каждой реплики настройте необходимые разрешения. Убедитесь, что установлены соответствующие уровни авторизации, предоставляя доступ к требуемому персоналу при сохранении стандартов безопасности.

4. Параллельное прием данных. Чтобы обеспечить согласованность и готовность данных в нескольких регионах, загрузите один и тот же набор данных в каждую базу данных KQL одновременно с приемом данных.

Поток событий

Поток событий на платформе Fabric — это централизованное место для записи, преобразования и маршрутизации событий в режиме реального времени в различные целевые точки (например, lakehouses, базы данных с KQL, наборы запросов) с использованием интерфейса без кода. До тех пор, пока назначения поддерживаются аварийным восстановлением, потоки событий не теряют данные. Поэтому клиенты должны использовать возможности аварийного восстановления этих целевых систем для обеспечения доступности данных.

Клиенты также могут достичь геоизбыточности путем развертывания идентичных рабочих нагрузок Eventstream в нескольких Azure регионах в рамках многосайтовых активных и активных стратегий. Благодаря многосайтовому активно-активному подходу клиенты могут получить доступ к рабочей нагрузке в любом развернутом регионе. Этот подход является самым сложным и дорогостоящим подходом к аварийному восстановлению, но может сократить время восстановления до нуля в большинстве ситуаций. Чтобы добиться полной геоизбыточности, клиенты могут

1. Создайте реплики источников данных в разных регионах.

2. Создание элементов Eventstream в соответствующих регионах.

3. Подключите эти новые элементы к идентичным источникам данных.

4. Добавьте одинаковые назначения для каждого потока событий в разных регионах.

Map

Элементы сопоставления из основного региона остаются недоступными для клиентов, и элементы сопоставления не реплицируются в вторичный регион.

Если вы хотите восстановить элемент Карты при аварии, настройте интеграцию Fabric Git и синхронизируйте элемент Карты с репозиторием Git.

Во время восстановления, после настройки нового региона или емкости в Fabric, можно использовать репозиторий для перестроения элемента карты в новой созданной рабочей области. Так как новая рабочая область пуста, Git sync получает содержимое из репозитория в пустую рабочую область. На этом шаге элемент карты возвращается к жизни.

Онтология

Пользователи ontology должны предпринять упреждающие шаги для подготовки к региональному аварийному восстановлению. Описанный ниже подход гарантирует, что после региональной аварии ваша онтология остается восстанавливаемой и может быть быстро восстановлена.

Самый простой и быстрый способ обеспечения восстановления — использовать интеграцию с Fabric Git и синхронизировать онтологию с репозиторием Azure DevOps (ADO). Если служба переключается на другой регион, этот репозиторий можно использовать для перестроения онтологии в только что созданной рабочей области.

Элементы онтологии в основном регионе недоступны клиентам после региональной аварии, а элементы онтологии не реплицируются во вторичный регион.

Чтобы восстановить элемент Ontology во время аварии, настройте интеграцию Fabric Git и synchronize элемент Ontology с репозиторием ADO заранее.

При восстановлении, после настройки нового региона и емкости в Fabric, вы можете использовать репозиторий для восстановления элемента Онтологии в новой рабочей области. Так как новая рабочая область пуста, Git sync извлекает содержимое из репозитория в рабочую область, эффективно восстанавливая элемент Ontology.

Транзакционная база данных

В этом руководстве описаны процедуры восстановления для взаимодействия с транзакционной базой данных.

SQL database

Чтобы защититься от регионального сбоя, пользователи баз данных SQL могут принимать упреждающие меры для периодического экспорта данных и использования экспортированных данных для повторного создания базы данных в новой рабочей области при необходимости.

Это можно сделать с помощью средства командной строки SqlPackage , который обеспечивает переносимость базы данных и упрощает развертывание базы данных.

1. Используйте средство SqlPackage для экспорта базы данных в .bacpac файл. Дополнительные сведения см. в статье "Экспорт базы данных с помощью SqlPackage ".
2. Сохраните .bacpac файл в безопасном расположении, которое находится в другом регионе, отличном от базы данных. Примеры включают хранение файла .bacpac в Lakehouse, расположенном в другом регионе, с использованием учетной записи Azure Storage с геоизбыточностью или другого защищенного носителя хранения в другом регионе.
3. Если база данных и регион SQL недоступны, можно использовать .bacpac файл с SqlPackage для повторного создания базы данных в рабочей области в новом регионе — Workspace C2. W2 в регионе B, как описано в приведенном выше сценарии. Выполните действия, описанные в статье "Импорт базы данных с помощью SqlPackage ", чтобы повторно создать базу данных с .bacpac файлом.

Повторно созданная база данных является независимой от исходной базы данных и отражает состояние данных во время операции экспорта.

Соображения по возврату к основному состоянию

Созданная база данных является независимой базой данных. Данные, добавленные в созданную базу данных, не будут отражены в исходной базе данных. Если вы планируете вернуться к исходной базе данных, когда домашний регион станет доступным, необходимо будет вручную сверять данные из повторно созданной базы данных с исходной базой данных.

Platform

Платформа относится к базовым общим службам и архитектуре, которые применяются ко всем рабочим нагрузкам. В этом разделе описаны процедуры восстановления для общих опытов. В ней рассматриваются библиотеки переменных.

Библиотека переменных

библиотеки переменных Microsoft Fabric позволяют разработчикам настраивать конфигурации элементов в рабочей области и предоставлять общий доступ к ним, упрощая управление жизненным циклом контента. С точки зрения аварийного восстановления пользователи библиотеки переменных должны заранее защититься от региональной аварии. Это можно сделать с помощью интеграции Fabric Git, которая гарантирует, что после региональной аварии библиотека переменных пользователя остается доступной. Чтобы восстановить библиотеку переменных, рекомендуется следующее:

• Используйте интеграцию Fabric Git для синхронизации библиотеки переменных с репозиторием ADO. В случае аварии репозиторий можно использовать для перестроения библиотеки переменных в созданной рабочей области. Выполните следующие действия.

  1. Подключите рабочую область к репозиторию Git, как описано здесь.
  2. Не забудьте синхронизировать WS и репозиторий с коммитом и апдейтом.
  3. Восстановление. В случае аварии используйте репозиторий для перестроения библиотеки переменных в новой рабочей области:

• В созданной рабочей области снова подключитесь к репозиторию Azure ADO и синхронизируйте их.

• Все элементы Fabric в этом репозитории автоматически скачиваются в новое рабочее пространство.

• После синхронизации элементов из Git откройте библиотеки переменных в новой рабочей области и вручную выберите нужный активный набор значений.

Управляемые клиентом ключи для рабочих областей Fabric

Вы можете использовать управляемые клиентом ключи (CMK), хранящиеся в Azure Key Vault, чтобы добавить дополнительный уровень шифрования на вершине ключей, управляемых Microsoft для неактивных данных. В случае, если Fabric становится недоступным или неработоспособным в регионе, его компоненты будут переключаться на резервную копию. Во время переключения на резервную систему функция CMK поддерживает операции только для чтения. Пока служба Azure Key Vault остается работоспособной, и разрешения для хранилища сохраняются, Fabric будет продолжать подключаться к ключу и обычно читать данные. Это означает, что во время переключения при отказе не поддерживаются следующие операции: включение и выключение настройки CMK рабочей области и обновление ключа.

Дополнительные сведения

• руководство по аварийному восстановлению Microsoft Fabric