Настройка группы отработки отказа — CLI

  • Статья

В этой статье объясняется, как настроить аварийное восстановление для Управляемый экземпляр SQL, включенных Azure Arc с помощью ИНТЕРФЕЙСА командной строки. Прежде чем продолжить, просмотрите сведения и предварительные требования в Управляемый экземпляр SQL, включенных Azure Arc — аварийное восстановление.

Необходимые компоненты

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

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

Примечание.

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

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

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

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

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

Diagram showing a properly configured distributed availability group.

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

Группы отработки отказа в службах данных 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 этом случае следует указать путь, содержащий файл сертификата зеркало, созданный из первичного экземпляра, как описано выше.

    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 подключенном режиме с помощью API ARM:

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

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

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

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

Примечание.

--partner-sync-mode Если он был настроен какsync, его необходимо сбросить до async того, когда вторичный будет повышен до первичного.

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

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 для запуска выставления счетов для используемых виртуальных ядер.

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