Настройка группы аварийного переключения для Azure SQL Управляемого экземпляра

Область применения: Управляемый экземпляр SQL Azure

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

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

Предварительные условия

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

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

Требования настройки

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

• Вторичный управляемый экземпляр должен быть пустым без каких-либо пользовательских баз данных.
• Конфигурация основного и дополнительного экземпляра должна быть одинаковой, чтобы обеспечить, чтобы вторичный экземпляр может устойчиво обрабатывать изменения, реплицированные из основного экземпляра, в том числе в периоды пиковых действий. К ним относятся размер вычислительных ресурсов, размер хранилища и уровень служб.
• Диапазон IP-адресов для виртуальной сети первичного экземпляра не должен перекрываться с диапазоном адресов виртуальной сети для вторичного управляемого экземпляра или любой другой виртуальной сети, пиринговой с первичной или вторичной виртуальной сетью.
• Оба экземпляра должны находиться в одной зоне DNS. При создании вторичного управляемого экземпляра необходимо указать идентификатор зоны DNS первичного экземпляра. Если это не так, идентификатор зоны создается в виде случайной строки при создании первого экземпляра в каждой виртуальной сети, а тот же идентификатор назначается всем другим экземплярам в одной подсети. После назначения зону DNS изменить нельзя.
• Правила групп безопасности сети (NSG) для подсетей всех экземпляров должны иметь открытые входящие и исходящие TCP-подключения для порта 5022 и диапазона портов 11000–11999, чтобы обеспечить взаимодействие между двумя экземплярами.
• Управляемые экземпляры следует развертывать в парных регионах по соображениям производительности. Управляемые экземпляры, находящиеся в геопарированных регионах, получают значительно более высокую скорость георепликации по сравнению с непарными регионами.
• Оба экземпляра должны использовать ту же политику обновления.

Создание вторичного экземпляра

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

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

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

Установка подключения между экземплярами

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

• Пиринг глобальной виртуальной сети
• Azure ExpressRoute
• VPN-шлюзы

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

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

• Сетевые устройства, такие как брандмауэры или сетевые виртуальные устройства (NVAs), не блокируют трафик на входящих и исходящих соединениях для порта 5022 (TCP) и диапазона портов 11000-11999.
• Маршрутизация настроена правильно, а асимметричная маршрутизация исключена.
• При развертывании групп отработки отказа в сетевой топологии концентратора и периферийной сети между регионами, чтобы избежать проблем с скоростью подключения и репликации, трафик репликации должен проходить непосредственно между двумя подсетями управляемого экземпляра, а не направляться через сети концентраторов.

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

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Настройка портов и правил NSG

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

• Таблица маршрутизации и группы сетевой безопасности, назначенные подсетям управляемого экземпляра, не используются совместно в двух соединенных виртуальных сетях.
• Правила группы безопасности сети (NSG) в обеих подсетях, в которых размещается каждый экземпляр, разрешает входящий и исходящий трафик к другому экземпляру через порт 5022 и диапазон портов 11000–11999.

Вы можете настроить связь портов и правила группы безопасности сети с помощью портала Azure и PowerShell.

Создайте группу резервирования

Создайте группу аварийного переключения для своих управляемых экземпляров, используя портал Azure или PowerShell.

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Тестовая отработка отказа

Проверьте переключение группы переключения при отказе с помощью портала Azure или PowerShell.

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Отслеживание переключения при отказе в журнале активности

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

1. Перейдите к управляемому экземпляру SQL в портале Azure.

2. Выберите журнал действий , чтобы открыть область журнала действий .

3. Удалите все фильтры для ресурса.

4. Искать операции с именем Failover Azure SQL Database failover group:

   

Изменить существующую группу переключения

Можно изменить существующую группу аварийного переключения, например, изменить политику аварийного переключения с помощью портала Azure, PowerShell, Azure CLI и REST API.

Определение конечной точки прослушивателя

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

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

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

• Конечная точка слушателя чтения и записи маршрутизации в виде fog-name.dns-zone.database.windows.net направляет трафик к основному экземпляру.
• Конечная точка прослушивателя только для чтения в виде fog-name.secondary.dns-zone.database.windows.net, направляет трафик во вторичный экземпляр.

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

Вы можете создать группу отработки отказа между управляемыми экземплярами SQL в двух разных подписках, если подписки связаны с тем же арендатором Microsoft Entra.

• При использовании API PowerShell можно сделать это, указав параметр PartnerSubscriptionId для вторичного управляемого экземпляра SQL.
• При использовании REST API каждый идентификатор экземпляра, входящий в параметр properties.managedInstancePairs, может иметь собственный идентификатор подписки.
• портал Azure не поддерживает создание групп автоматического переключения в разных подписках.

Предотвращение потери критически важных данных

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

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

Изменение дополнительного региона

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

1. Создайте экземпляр C с тем же размером, что и A в той же зоне DNS.
2. Удалите группу отработки отказа между экземплярами A и B. На этом этапе попытки входа начинаются сбоем, так как псевдонимы SQL для прослушивателей группы отработки отказа были удалены, и шлюз не распознает имя группы отработки отказа. Вторичные базы данных отключаются от первичных и становятся доступными для чтения и записи.
3. Создайте группу аварийного переключения с тем же именем между экземплярами A и C. Следуйте инструкциям в руководстве по настройке группы аварийного переключения. Это операция, связанная с объемом данных, и завершается, когда все базы данных из экземпляра A инициализированы и синхронизированы.
4. Удалите экземпляр B, если не требуется избежать ненужных расходов.

Изменение основного региона

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

1. Создайте экземпляр C с тем же размером, что и B в той же зоне DNS.
2. Инициируйте ручное переключение экземпляра B, чтобы сделать его новым основным. Экземпляр A автоматически становится новым вторичным экземпляром.
3. Удалите группу отказоустойчивости между экземплярами A и B. На этом этапе попытки входа с использованием конечных точек группы отказоустойчивости начинают терпеть неудачу. Базы данных-получатели А отключены от первичных и становятся базами данных с возможностью чтения и записи.
4. Создайте группу отказоустойчивости с одинаковым именем между экземплярами B и C. Это операция, зависящая от объема данных, и завершается, когда все базы данных из экземпляра B инициализированы и синхронизированы с экземпляром C. На этом этапе попытки входа перестают завершаться неудачно.
5. Вручную выполните переключение экземпляра C на основную роль. Экземпляр B автоматически становится новым вторичным экземпляром.
6. Удалите экземпляр A, если не требуется избежать ненужных расходов.

Изменение политики обновления

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

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

Включение сценариев, зависящих от объектов из системных баз данных

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

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

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Дополнительные сведения см. в статье Репликация имен входа и заданий агента.

Синхронизация свойств экземпляра и политик хранения

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

Масштабирование инстансов

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

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

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

• Основные и вспомогательные экземпляры можно изменять в масштабе вверх или вниз на другой размер вычислительных ресурсов как в одном и том же уровне обслуживания, так и на другой.
• При масштабировании на одном уровне служб сначала масштабируйте гео-вторичную, а затем масштабируйте основной.
• При уменьшении масштаба в пределах одного уровня служб переверните порядок: сначала уменьшите масштаб основного, а затем уменьшите масштаб вторичного.
• Следуйте той же последовательности при изменении конфигурации вашей установки. Если вы масштабируете ресурсы вверх, сначала сделайте это на вторичном. Если вы снижаете масштабирование, делайте это сначала на основном компоненте. Это относится к следующим изменениям конфигурации экземпляра:
  • Обновление или понижение уровня служб.
  • Изменение количества виртуальных ядер.
  • Масштабирование размера хранилища.
  • Изменение выделения памяти экземпляра нового поколения общего назначения.

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

• Вариант 1. Сначала масштабируйте уровень служб (сохраняйте хранилище и виртуальные ядра одинаково), выполнив описанный выше порядок обновления или понижения. Затем масштабируйте хранилище и виртуальные ядра отдельно.
• Вариант 2. Сначала масштабируйте хранилище (сохраняйте уровень служб и виртуальные ядра одинаково), после описанного выше порядка обновления или понижения. Затем масштабируйте уровень служб и виртуальные ядра отдельно.

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

Разрешения

Управление разрешениями для группы резервирования осуществляется через управление доступом на основе ролей Azure (Azure RBAC).

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

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

Ограничения

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

• Группы отказоустойчивости не могут быть созданы между двумя экземплярами в одном регионе Azure.
• Экземпляр может участвовать только в одной группе аварийного переключения в любой конкретный момент.
• Нельзя создать группу аварийного переключения между двумя экземплярами, принадлежащими разным арендаторам Azure.
• Создание группы отработки отказа между двумя экземплярами в разных группах ресурсов или подписках поддерживается только с использованием Azure PowerShell или REST API, а не через портал Azure или через Azure CLI. После создания группы резервирования она отображается в портале Azure, а все операции поддерживаются в портале Azure или в Azure CLI.
• Если инициализация всех баз данных не завершается в течение 7 дней, создание группы резервного переключения становится неудачным, а все успешно реплицированные базы данных удаляются из вторичной копии.
• Создание группы аварийного переключения с экземпляром, настроенным через ссылку управляемого экземпляра, в настоящее время не поддерживается.
• Нельзя создавать группы аварийного восстановления между экземплярами, если любой из них находится в пуле экземпляров.
• Базы данных, перенесенные в Управляемый экземпляр SQL Azure с помощью службы воспроизведения журналов (LRS), не могут быть добавлены в группу отработки отказа, пока не будет выполнен переходный шаг.

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

• Невозможно переименовать группы аварийного переключения. Вам нужно будет удалить группу и создать ее повторно с другим именем.
• Группа отказоустойчивости содержит ровно два управляемых экземпляра. Добавление дополнительных экземпляров в группу аварийного переключения не поддерживается.
• Полные резервные копии автоматически создаются:
  • перед начальной загрузкой данных и может заметно отложить начало процесса начальной загрузки.
  • после переключения на резервный узел и может отложить или предотвратить последующее переключение.
• Переименование базы данных не поддерживается для баз данных в группе автоматического переключения. Чтобы переименовать базу данных, необходимо временно удалить группу резервного копирования (отработки отказа).
• Системные базы данных не реплицируются на вторичный экземпляр в группе переключения при отказе. Таким образом, сценарии, зависящие от объектов системных баз данных, например, имени для входа на сервер и заданий агента, нуждаются в создании объектов вручную в дополнительных экземплярах, а также в ручной синхронизации после внесения любых изменений в основной экземпляр. Единственным исключением является ключ главного службы (SMK) для управляемого экземпляра SQL, который автоматически реплицируется во вторичный экземпляр во время создания группы отработки отказа. Однако любые последующие изменения SMK на основном экземпляре не будут реплицированы в дополнительный экземпляр. Для получения дополнительных сведений см. статью Включение сценариев, зависящих от объектов из системных баз данных.
• При добавлении новых баз данных в группу автоматического переключения запланированное переключение недоступно до тех пор, пока новая база данных не будет применена к вторичной реплике и синхронизирована. Принудительный отказ по-прежнему доступен во время этого процесса.
• Для масштабирования экземпляров внутри группы отработки отказа просмотрите Масштабирование экземпляров в группе отработки отказа.
• Управляемые экземпляры SQL в группе отработки отказа должны иметь ту же политику обновления, хотя можно изменить политику обновления для экземпляров в группе отработки отказа.

Программное управление группами переключения при отказе

Группами аварийного переключения также можно управлять программным способом с помощью Azure PowerShell, Azure CLI и REST API. В приведенных ниже таблицах описан доступный для этого набор команд. Группы аварийного восстановления включают набор API Azure Resource Manager для управления, включая REST API Azure SQL Database и командлеты Azure PowerShell. Для этих API требуется использование групп ресурсов и поддержка управления доступом на основе ролей в Azure (Azure RBAC). Дополнительные сведения о том, как реализовать контроль доступа на основе ролей, см. в статье Управление доступом на основе ролей (Azure RBAC).

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

• Добавление управляемого экземпляра в группу отказоустойчивости
• Группы аварийного восстановления
• Настройка резервной реплики