Настройка группы резервирования — CLI

В этой статье объясняется, как настроить аварийное восстановление для Управляемого экземпляра SQL, используя Azure Arc и CLI. Прежде чем продолжить, ознакомьтесь с информацией и предварительными требованиями в разделе о аварийном восстановлении SQL Managed Instance, включенного в Azure Arc.

Предпосылки

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

• Контроллер данных Azure Arc и управляемый экземпляр SQL с поддержкой Arc, подготовленный на первичном сайте как --license-type один из BasePrice или LicenseIncluded.
• Контроллер данных Azure Arc и управляемый экземпляр SQL с поддержкой Arc, подготовленный на вторичном сайте с идентичной конфигурацией, как основной с точки зрения:
  • ЦП
  • Память
  • Хранение
  • Уровень служб
  • Сопоставление
  • Другие параметры экземпляра
• Экземпляр на вторичном сайте требуется --license-type как DisasterRecovery. Этот экземпляр должен быть новым, без каких-либо пользовательских объектов.

Процесс развертывания

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

1. Создание настраиваемого ресурса для распределенной группы доступности на первичном сайте
2. Создание настраиваемого ресурса для распределенной группы доступности на вторичном сайте
3. Копирование двоичных данных из сертификатов зеркального отображения
4. Настройка распределенной группы доступности между основными и вторичными сайтами в sync режиме или async режиме

На следующем рисунке показана правильно настроенная распределенная группа доступности:

Режимы синхронизации

Группы аварийного переключения в службах данных Azure Arc поддерживают два режима синхронизации — sync и async. Режим синхронизации напрямую влияет на синхронизацию данных между экземплярами и, возможно, производительность основного управляемого экземпляра.

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

Настройка группы аварийного переключения Azure — прямой режим

Выполните приведенные ниже действия, если службы данных Azure Arc развертываются в directly подключенном режиме.

Как только предварительные условия будут выполнены, выполните следующую команду, чтобы создать группу восстановления после отказа Azure между двумя экземплярами:

az sql instance-failover-group-arc create --name <name of failover group> --mi <primary SQL MI> --partner-mi <Partner MI> --resource-group <name of RG> --partner-resource-group <name of partner MI RG>

Пример:

az sql instance-failover-group-arc create --name sql-fog --mi sql1 --partner-mi sql2 --resource-group rg-name --partner-resource-group rg-name

Вышеприведенная команда:

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

Настройка группы аварийного переключения Azure — косвенный режим

Выполните приведенные ниже действия, если службы данных Azure Arc развертываются в indirectly подключенном режиме.

1. Подготовьте управляемый экземпляр на первичном сайте.

   az sql mi-arc create --name <primaryinstance> --tier bc --replicas 3 --k8s-namespace <namespace> --use-k8s
   

2. Переключите контекст на дополнительный кластер, запустив kubectl config use-context <secondarycluster> и подготовив управляемый экземпляр на вторичном сайте, который будет экземпляром аварийного восстановления. На этом этапе системные базы данных не являются частью автономной группы доступности.

   Замечание

   Важно указать --license-type DisasterRecoveryдля управляемого экземпляра. Это позволит резервному экземпляру инициализироваться от первичного экземпляра в основном центре обработки данных. Обновление этого свойства после развертывания не будет иметь такого же эффекта.

   az sql mi-arc create --name <secondaryinstance> --tier bc --replicas 3 --license-type DisasterRecovery --k8s-namespace <namespace> --use-k8s
   

3. Сертификаты зеркального отображения — двоичные данные в свойстве сертификата зеркального отображения управляемого экземпляра необходимы для создания группы отказоустойчивости экземпляров CR (настраиваемый ресурс).

   Это можно сделать несколькими способами:

   (a) При использовании az интерфейса командной строки сначала создайте файл сертификата зеркального отображения, а затем укажите этот файл при настройке группы переключения на резервный экземпляр, чтобы двоичные данные считывались из файла и копировались в CR. Файлы сертификата не требуются после создания группы переключения при сбое.

   (b) При использовании kubectl напрямую скопируйте и вставьте двоичные данные из управляемого экземпляра CR в файл yaml, который будет использоваться для создания группы резервного переключения экземпляра.

   Используя (a) выше:

   Создайте файл сертификата зеркального отображения для основного экземпляра:

   az sql mi-arc get-mirroring-cert --name <primaryinstance> --cert-file </path/name>.pem​ --k8s-namespace <namespace> --use-k8s
   

   Пример:

   az sql mi-arc get-mirroring-cert --name sqlprimary --cert-file $HOME/sqlcerts/sqlprimary.pem​ --k8s-namespace my-namespace --use-k8s
   

   Подключитесь к дополнительному кластеру и создайте файл зеркального сертификата для вторичного экземпляра.

   az sql mi-arc get-mirroring-cert --name <secondaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s
   

   Пример:

   az sql mi-arc get-mirroring-cert --name sqlsecondary --cert-file $HOME/sqlcerts/sqlsecondary.pem --k8s-namespace my-namespace --use-k8s
   

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

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

   Замечание

   Убедитесь, что экземпляры SQL имеют разные имена для первичных и вторичных сайтов, а shared-name значение должно совпадать на обоих сайтах.

   az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary failover group resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s
   

   Пример:

   az sql instance-failover-group-arc create --shared-name myfog --name primarycr --mi sqlinstance1 --role primary --partner-mi sqlinstance2  --partner-mirroring-url tcp://10.20.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance2.pem --k8s-namespace my-namespace --use-k8s
   

   На вторичном экземпляре выполните следующую команду, чтобы настроить пользовательский ресурс группы отказоустойчивости. В --partner-mirroring-cert-file этом случае следует указать путь, содержащий файл сертификата зеркалирования, созданного из первичного экземпляра, как описано в 3(a).

   az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for secondary failover group resource> --mi <local SQL managed instance name> --role secondary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<primary IP> --partner-mirroring-cert-file <primary.pem> --k8s-namespace <namespace> --use-k8s
   

   Пример:

   az sql instance-failover-group-arc create --shared-name myfog --name secondarycr --mi sqlinstance2 --role secondary --partner-mi sqlinstance1  --partner-mirroring-url tcp://10.10.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance1.pem --k8s-namespace my-namespace --use-k8s
   

Получение состояния работоспособности группы отказоустойчивости Azure

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

Выполните следующую команду на первичном и/или вторичном узле, чтобы перечислить пользовательский ресурс групп аварийного переключения:

kubectl get fog -n <namespace>

Опишите пользовательский ресурс для получения состояния группы отказоустойчивости, следуя перечисленным ниже шагам:

kubectl describe fog <failover group cr name> -n <namespace>

Операции группы резервирования

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

Возможные сценарии переключения при сбоях:

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

  • выполните отработку отказа вручную из первичного во вторичный без потери данных, для этого установите role=secondary на первичном экземпляре SQL MI.

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

  • Основной управляемый экземпляр SQL, обеспеченный Azure Arc, недоступен, неработоспособен или не поддается подключению.
  • Вторичный управляемый экземпляр SQL, развернутый с помощью Azure Arc, должен быть принудительно повышен до первичного с потенциальной потерей данных.
  • Когда исходный основной управляемый экземпляр SQL, активированный с помощью Azure Arc, возвращается в режим "онлайн", он будет отображаться как Primary роль с неработоспособным состоянием и его необходимо переключить на роль secondary, чтобы он мог присоединиться к группе отказоустойчивости и данные могли быть синхронизированы.

Ручное переключение (без потери данных)

Используйте az sql instance-failover-group-arc update ... группу команд, чтобы инициировать переключение с основного на резервный. Все ожидающие транзакции на гео-первичном экземпляре реплицируются в гео-вторичный экземпляр до операции переключения.

Режим прямого подключения

Выполните следующую команду, чтобы инициировать переключение на резерв вручную в direct подключенном режиме с использованием ARM API:

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <primary instance> --role secondary --resource-group <resource group>

Пример:

az sql instance-failover-group-arc update --name myfog --mi sqlmi1 --role secondary --resource-group myresourcegroup

Косвенно подключенный режим

Выполните следующую команду, чтобы инициировать отработку отказа вручную в indirect подключенном режиме с помощью API kubernetes:

az sql instance-failover-group-arc update --name <name of failover group resource> --role secondary --k8s-namespace <namespace> --use-k8s 

Пример:

az sql instance-failover-group-arc update --name myfog --role secondary --k8s-namespace my-namespace --use-k8s 

Принудительное переключение при отказе с потерей данных

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

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

Режим прямого подключения

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <instance> --role force-primary-allow-data-loss --resource-group <resource group> --partner-sync-mode async

Пример:

az sql instance-failover-group-arc update --name myfog --mi sqlmi2 --role force-primary-allow-data-loss --resource-group myresourcegroup --partner-sync-mode async

Косвенно подключенный режим

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-primary-allow-data-loss --partner-sync-mode async

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

Режим прямого подключения

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <old primary instance> --role force-secondary --resource-group <resource group>

Косвенно подключенный режим

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-secondary

При желании, --partner-sync-mode можно обратно настроить в режим sync.

Операции после восстановления отказа

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

• Обновите строку подключения для приложений, чтобы подключиться к вновь созданному основному управляемому экземпляру Arc SQL
• Если вы планируете продолжить выполнение рабочей нагрузки на вторичной площадке, обновите --license-type до BasePrice или LicenseIncluded, чтобы инициировать выставление счетов за потребляемые виртуальные ядра.

Связанный контент

• Обзор: Управляемый экземпляр SQL, поддерживаемый Azure Arc для обеспечения непрерывности бизнеса
• Настройка группы резервирования на случай отказа — портал