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

Статья
08/14/2024

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

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

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

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

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

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

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

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

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

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

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

Портал Azure
PowerShell

Создание виртуальной сети

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

Проверьте адресное пространство для основного экземпляра. Перейдите к ресурсу виртуальной сети для основного экземпляра в портал Azure и в разделе "Параметры" выберите адресное пространство. Проверьте диапазон в диапазоне адресов:
Создайте виртуальную сеть, которую планируется использовать для дополнительного экземпляра, перейдя на страницу "Создание виртуальной сети ".
На вкладке "Основы" страницы "Создание виртуальной сети ":
1. Выберите группу ресурсов, которую вы планируете использовать для дополнительного экземпляра. Создайте новый, если он еще не существует.
2. Укажите имя виртуальной сети, например vnet-sql-mi-secondary.
3. Выберите регион, связанный с регионом, где находится основной экземпляр.
На вкладке IP-адресов страницы "Создание виртуальной сети ":
1. Удалите адресное пространство для удаления существующего адресного пространства IPv4.
2. После удаления адресного пространства выберите "Добавить адресное пространство IPv4", чтобы добавить новое пространство, а затем укажите пространство IP-адресов, отличное от адресного пространства, используемого виртуальной сетью первичного экземпляра. Например, если текущий основной экземпляр использует адресное пространство 10.0.0.16, введите 10.1.0.0/16 адресное пространство виртуальной сети, которую планируется использовать для вторичного экземпляра.
3. Используйте +Добавить подсеть, чтобы добавить подсеть по умолчанию со значениями по умолчанию.
4. Используйте + добавьте подсеть, чтобы добавить пустую подсеть с именем ManagedInstance , которая будет выделена вторичному экземпляру, используя диапазон адресов, отличный от подсети по умолчанию. Например, если основной экземпляр использует диапазон адресов от 10.0.0.0 до 10.0.255.255, укажите диапазон 10.1.1.0 - 10.1.1.255 подсети для подсети вторичного экземпляра.
Используйте проверку и создание , чтобы просмотреть параметры, а затем использовать create для создания новой виртуальной сети.

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

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

Перейдите к Управляемый экземпляр SQL Azure создания в портал Azure.
На вкладке "Основы" страницы "Создание Управляемый экземпляр SQL Azure":
1. Выберите регион для дополнительного экземпляра, который связан с основным экземпляром.
2. Выберите уровень служб, соответствующий уровню служб основного экземпляра.
На вкладке "Сеть" страницы "Создание Управляемый экземпляр SQL Azure" используйте раскрывающийся список в разделе "Виртуальная сеть/ подсеть", чтобы выбрать виртуальную сеть и подсеть, которую вы ранее создали:
На вкладке "Дополнительные параметры" страницы "Создать Управляемый экземпляр SQL Azure" выберите "Да", чтобы использовать отработку отказа вторичную, а затем выберите соответствующий основной экземпляр из раскрывающегося списка.
Настройте остальную часть экземпляра в соответствии с вашими бизнес-потребностями, а затем создайте его с помощью проверки и создания.

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

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

Команду Get-AzSqlInstance можно использовать для параметризации идентификатора зоны DNS первичного экземпляра, а затем передать его параметру DnsZonePartner команды New-AzSqlInstance:

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

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

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

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

Внимание

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

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

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

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

Портал Azure
PowerShell

В портал Azure перейдите к ресурсу виртуальной сети для основного управляемого экземпляра.
Выберите пиринги в разделе "Параметры", чтобы открыть страницу пиринга, а затем использовать +Добавить из панели команд, чтобы открыть страницу "Добавить пиринг".

На странице "Добавление пиринга" введите или выберите значения для следующих параметров:

Настройки	Описание
Сводка по удаленной виртуальной сети
Имя пиринговой связи	Имя для пиринга должно быть уникальным в пределах виртуальной сети. Для этой статьи используется `Fog-peering`.
Модель развертывания виртуальной сети	Выберите Resource Manager.
Я знаю идентификатор ресурса	Этот флажок можно оставить без флажка, если вы не знаете идентификатор ресурса.
Отток подписок	Выберите подписку из раскрывающегося списка.
Виртуальная сеть	Выберите виртуальную сеть для вторичного экземпляра из раскрывающегося списка.
Параметры пиринга удаленной виртуальной сети
Разрешить "вторичной виртуальной сети" доступ к "основной виртуальной сети"	Установите флажок, чтобы разрешить обмен данными между двумя сетями. Если разрешить обмен данными между виртуальными сетями, то ресурсы, подключенные к каждой из них, будут взаимодействовать между собой с той же пропускной способностью и задержкой, что и ресурсы, подключенные к одной и той же виртуальной сети. Обмен данными между ресурсами двух виртуальных сетей осуществляется по частной сети Azure.
Разрешить "вторичной виртуальной сети" получать переадресованный трафик из первичной виртуальной сети.	Этот флажок можно установить или снять с этого флажка. Это руководство работает. Дополнительные сведения см. в разделе "Создание пиринга".
Разрешить шлюзу или серверу маршрутизации в "вторичной виртуальной сети" перенаправить трафик в "первичную виртуальную сеть"	Этот флажок можно установить или снять с этого флажка. Это руководство работает. Дополнительные сведения см. в разделе "Создание пиринга".
Включение "вторичной виртуальной сети" для использования удаленного шлюза или сервера маршрутизации основной виртуальной сети	Оставьте этот флажок без флажка. Дополнительные сведения о других доступных параметрах см. в разделе "Создание пиринга".
Сводка по локальной виртуальной сети
Имя пиринговой связи	Имя того же пиринга, используемого для удаленной виртуальной сети. Для этой статьи используется `Fog-peering`.
Разрешить "основной виртуальной сети" получить доступ к "вторичной виртуальной сети"	Установите флажок, чтобы разрешить обмен данными между двумя сетями. Если разрешить обмен данными между виртуальными сетями, то ресурсы, подключенные к каждой из них, будут взаимодействовать между собой с той же пропускной способностью и задержкой, что и ресурсы, подключенные к одной и той же виртуальной сети. Обмен данными между ресурсами двух виртуальных сетей осуществляется по частной сети Azure.
Разрешить "основной виртуальной сети" получать переадресованный трафик из "вторичной виртуальной сети"	Этот флажок можно установить или снять с этого флажка. Это руководство работает. Дополнительные сведения см. в разделе "Создание пиринга".
Разрешить шлюзу или серверу маршрутизации в первичной виртуальной сети перенаправить трафик в "вторичную виртуальную сеть"	Этот флажок можно установить или снять с этого флажка. Это руководство работает. Дополнительные сведения см. в разделе "Создание пиринга".
Включение "основной виртуальной сети" для использования удаленного шлюза или сервера маршрутизации вторичной виртуальной сети	Оставьте этот флажок без флажка. Дополнительные сведения о других доступных параметрах см. в разделе "Создание пиринга".

Используйте "Добавить", чтобы настроить пиринг с выбранной виртуальной сетью и автоматически перейти на страницу пиринга, в которой показаны две сети:

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


# 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

В этом фрагменте кода используются следующие команды:

Команда	Примечания.
1. Get-AzVirtualNetwork	Получает виртуальную сеть в группе ресурсов.
2. Add-AzVirtualNetworkPeering	Добавляет пиринг в виртуальную сеть.
3. Get-AzVirtualNetworkPeering	Получает пиринг для виртуальной сети.

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

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

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

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

Портал Azure
PowerShell

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

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

На странице "Добавление правила безопасности для входящего трафика" введите или выберите значения для следующих параметров:

Настройки	Рекомендуемое значение	Description
Исходный код	IP-адреса или тег службы	Фильтр для источника связи. IP-адрес является наиболее безопасным и рекомендуется для рабочих сред. Тег службы подходит для непроизводственных сред.
Тег службы источника	Если вы выбрали тег службы в качестве источника, укажите `VirtualNetwork` в качестве исходного тега.	Теги по умолчанию — это стандартные идентификаторы, представляющие категорию IP-адресов. Тег VirtualNetwork обозначает все адресные пространства виртуальной и локальной сети.
Исходные IP-адреса	Если в качестве источника выбраны IP-адреса, укажите IP-адрес вторичного экземпляра.	Укажите диапазон адресов с помощью нотации CIDR (например, 192.168.99.0/24 или 2001:1234::/64) или IP-адрес (например, 192.168.99.0 или 2001:1234::). Вы также можете указать разделенный запятыми список IP-адресов или диапазонов адресов с помощью IPv4 или IPv6.
Диапазоны исходных портов	5022	Это указывает, на каком трафике портов будет разрешен этот правило.
Service	Пользовательское	Служба указывает целевой протокол и диапазон портов для этого правила.
Диапазоны портов назначения	5022	Это указывает, на каком трафике портов будет разрешен этот правило. Этот порт должен соответствовать диапазону исходного порта.
Действие	Allow	Разрешить обмен данными по указанному порту.
Протокол	TCP	Определяет протокол для связи через порт.
Приоритет	1200	Правила обрабатываются в порядке приоритета; чем ниже число, тем выше приоритет.
Имя.	allow_geodr_inbound	Имя правила.
Description	Необязательно	Вы можете указать описание или оставить это поле пустым.

Нажмите кнопку "Добавить ", чтобы сохранить параметры и добавить новое правило.

Повторите эти действия, чтобы добавить другое правило безопасности для диапазона 11000-11999 портов с таким именем, как allow_redirect_inbound , и приоритет немного выше правила 5022, например 1100.
В разделе Параметры выберите Правила безопасности для исходящего трафика. Убедитесь, что у вас уже есть правила, разрешающие трафик для порта 5022, и диапазон 11000–11999. Если вы делаете, и источник соответствует вашим бизнес-потребностям, пропустите этот шаг. Если правила не существуют, или если вы хотите использовать другой источник (например, более безопасный IP-адрес), удалите существующее правило, а затем нажмите кнопку +Добавить из панели команд, чтобы открыть страницу правила безопасности добавления исходящего трафика.
На странице "Добавление правила безопасности для исходящего трафика" используйте ту же конфигурацию для порта 5022 и диапазон11000-11999, что и для входящих портов.
Перейдите в группу безопасности сети для дополнительного экземпляра и повторите следующие действия, чтобы обе группы безопасности сети имели следующие правила:
- Разрешить входящий трафик через порт 5022
- Разрешить входящий трафик в диапазоне портов 11000-11999
- Разрешить исходящий трафик через порт 5022
- Разрешить исходящий трафик в диапазоне портов 11000-11999

Создание группы отработки отказа

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

Портал
PowerShell

Создайте группу отработки отказа для своих Управляемых экземпляров SQL, используя портал Azure.

На портале Azure в меню слева выберите Azure SQL. Если Azure SQL нет в списке, выберите элемент Все службы и введите "Azure SQL" в поле поиска. (Необязательно) Выберите звезду рядом с SQL Azure, чтобы добавить ее в качестве избранного элемента в навигацию слева.
Выберите основной управляемый экземпляр, добавляемый в группу отработки отказа.
В разделе Управление данными выберите группы отработки отказа, а затем используйте группу "Добавить", чтобы открыть страницу группы отработки отказа экземпляра:
На странице группы отработки отказа экземпляра:
1. Первичный управляемый экземпляр предварительно выбран.
2. В разделе Имя группы отработки отказа введите имя группы отработки отказа.
3. В разделе "Вторичный управляемый экземпляр" выберите управляемый экземпляр, который вы хотите использовать в качестве вторичного в группе отработки отказа.
4. Выберите политику отработки отказа чтения и записи из раскрывающегося списка. Рекомендуется вручную предоставить вам контроль над отработой отказа.
5. Оставьте значение "Включить отработку отказа" в off, если вы не планируете использовать эту реплику только для аварийного восстановления.
6. Создайте параметры и создайте группу отработки отказа.
После запуска развертывания группы отработки отказа вы вернеесь на страницу групп отработки отказа. Страница обновляется, чтобы отобразить новую группу отработки отказа после завершения развертывания.

Используйте New-AzSqlDatabaseInstanceFailoverGroup , чтобы создать группу отработки отказа для управляемых экземпляров с помощью 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.

Примечание.

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

Портал Azure
PowerShell

Протестируйте отработку отказа для группы отработки отказа с помощью портала Azure.

Перейдите к основному или вторичному управляемому экземпляру в портал Azure.
В разделе Управление данными выберите Группы отработки отказа.
На странице групп отработки отказа обратите внимание, какой экземпляр является основным экземпляром, и какой экземпляр является вторичным.
На странице групп отработки отказа выберите отработку отказа на панели команд. Выберите "Да " в предупреждении об отключении сеансов TDS и обратите внимание на последствия лицензирования.
На странице групп отработки отказа после успешной отработки отказа экземпляры переключают роли, чтобы предыдущая вторичная стала новой первичной, а предыдущая первичная становится новой вторичной.

Внимание

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

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

Проверка ролей каждого экземпляра

Используйте команду Get-AzSqlDatabaseInstanceFailoverGroup, чтобы подтвердить роли каждого экземпляра:


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

Отработка отказа на дополнительный экземпляр

Используйте Switch-AzSqlDatabaseFailoverGroup для отработки отказа в дополнительный экземпляр.

# 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

Проверка ролей каждого экземпляра

Используйте команду Get-AzSqlDatabaseInstanceFailoverGroup, чтобы подтвердить роли каждого экземпляра:


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

Восстановление группы отработки отказа на основном сервере

При необходимости используйте команду Switch-AzSqlDatabaseFailoverGroup , чтобы вернуться к основному экземпляру.


# 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, перейдите к управляемому экземпляру SQL и в разделе "Управление данными" выберите группы отработки отказа.

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

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

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

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

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

Внимание

Портал Azure не поддерживает создание групп отработки отказа в разных подписках. Для групп отработки отказа в разных подписках и (или) группах ресурсов отработка отказа не может быть инициирована вручную с помощью портал Azure из основного управляемого экземпляра SQL. Запустите ее из вспомогательного экземпляра геообъекта.

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

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

Примечание.

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

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

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

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

Примечание.

После выполнения шага 2 и до завершения шага 3 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра A.

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

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

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

Внимание

После завершения шага 3 и до завершения шага 4 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра A.

Внимание

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

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

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

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

Внимание

После изменения обновленной политики на always-up-date его изменение обратно в политику обновления SQL Server 2022 больше не возможно.

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

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

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

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

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

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

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

Масштабирование экземпляров

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

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

Разрешения

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

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

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

Операция управления	Разрешение	Область применения
Создание и обновление группы отработки отказа	`Microsoft.Sql/locations/instanceFailoverGroups/write`	Группы ресурсов первичного и вторичного управляемого экземпляра
Создание и обновление группы отработки отказа	`Microsoft.Sql/managedInstances/write`	Первичный и вторичный управляемый экземпляр
Группа отработки отказа отработки отказа	`Microsoft.Sql/locations/instanceFailoverGroups/failover/action`	Группы ресурсов первичного и вторичного управляемого экземпляра
Принудительное отработка отказа группы отработки отказа	`Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action`	Группы ресурсов первичного и вторичного управляемого экземпляра
Удаление группы отработки отказа	`Microsoft.Sql/locations/instanceFailoverGroups/delete`	Группы ресурсов первичного и вторичного управляемого экземпляра

Ограничения

Следует учитывать следующие ограничения.

Группы отработки отказа не могут быть созданы между двумя экземплярами в одном регионе Azure.
Невозможно переименовать группы отработки отказа. Вам нужно будет удалить группу и создать ее повторно с другим именем.
Группа отработки отказа содержит ровно два управляемых экземпляра. Добавление дополнительных экземпляров в группу отработки отказа не поддерживается.
Экземпляр может участвовать только в одной группе отработки отказа в любой момент.
Не удается создать группу отработки отказа между двумя экземплярами, принадлежащими разным клиентам Azure.
Создание группы отработки отказа между двумя экземплярами в разных группах ресурсов или подписках поддерживается только с помощью Azure PowerShell или REST API, а не портал Azure или Azure CLI. После создания группы отработки отказа она отображается в портал Azure, а все операции поддерживаются в портал Azure или Azure CLI. Отработка отказа должна быть инициирована из вторичного экземпляра.
Создание группы отработки отказа с экземпляром, настроенным с помощью ссылки на управляемый экземпляр, в настоящее время не поддерживается.
Переименование базы данных не поддерживается для баз данных в группе отработки отказа. Чтобы переименовать базу данных, необходимо временно удалить группу отработки отказа.
Системные базы данных не реплицируются на вторичный экземпляр в группе отработки отказа. Таким образом, сценарии, зависящие от объектов системных баз данных, например, имени для входа на сервер и заданий агента, нуждаются в создании объектов вручную в дополнительных экземплярах, а также в ручной синхронизации после внесения любых изменений в основной экземпляр. Единственным исключением является главный ключ службы (SMK) для Управляемый экземпляр SQL, который реплицируется автоматически в вторичный экземпляр во время создания группы отработки отказа. Однако любые последующие изменения SMK на основном экземпляре не будут реплицированы в дополнительный экземпляр. Для получения дополнительных сведений см. статью Включение сценариев, зависящих от объектов из системных баз данных.
Группы отработки отказа нельзя создавать между экземплярами, если они находятся в пуле экземпляров.
Например, внутри группы отработки отказа, изменение уровня служб на уровень "Следующее поколение общего назначения" не поддерживается. Сначала необходимо удалить группу отработки отказа перед изменением любой реплики, а затем повторно создать группу отработки отказа после того, как изменение вступает в силу.
Управляемые экземпляры SQL в группе отработки отказа должны иметь ту же политику обновления, хотя можно изменить политику обновления для экземпляров в группе отработки отказа.

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

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

Командлет	Description
New-AzSqlDatabaseInstanceFailoverGroup	Эта команда создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе
Set-AzSqlDatabaseInstanceFailoverGroup	Изменяет конфигурацию отказоустойчивого кластера
Get-AzSqlDatabaseInstanceFailoverGroup	Извлекает конфигурацию группы отработки отказа
Switch-AzSqlDatabaseInstanceFailoverGroup	Запускает отработку отказа группы отработки отказа на вторичный экземпляр
Remove-AzSqlDatabaseInstanceFailoverGroup	Удаляет группу отработки отказа.

Команда	Description
az sql instance-failover-group create	Создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе.
az sql instance-failover-group delete	Удаляет группу отработки отказа с сервера
az sql instance-failover-group show	Извлекает конфигурацию группы отработки отказа
az sql instance-failover-group update	Изменяет конфигурацию группы отработки отказа и (или) добавляет одну или несколько баз данных в группу отработки отказа
az sql instance-failover-group set-primary	Запускает отработку отказа группы отработки отказа на сервер-получатель

API	Description
Создание или обновление группы отработки отказа	Создает или обновляет конфигурацию группы отработки отказа
Удаление группы отработки отказа	Удаляет группу отработки отказа с экземпляра
Плановая отработка отказа	Активирует отработку отказа с текущего первичного экземпляра на этот экземпляр с полной синхронизацией данных.
Принудительная отработка отказа (возможна потеря данных)	Активирует отработку отказа с текущего первичного экземпляра на вторичный без синхронизации данных. Эта операция может привести к потере данных.
Получение группы отработки отказа	Извлекает конфигурацию группы отработки отказа.
Перечисление групп отработки отказа – Перечисление по расположению	Перечисляет группы отработки отказа в расположении.

Поделиться через

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

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

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

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

Создание виртуальной сети

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

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

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

Создание группы отработки отказа

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

Проверка ролей каждого экземпляра

Отработка отказа на дополнительный экземпляр

Проверка ролей каждого экземпляра

Восстановление группы отработки отказа на основном сервере

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

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

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

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

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

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

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

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

Масштабирование экземпляров

Разрешения

Ограничения

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

Обратная связь

Дополнительные ресурсы

Поделиться через

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

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

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

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

Создание виртуальной сети

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

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

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

Создание группы отработки отказа

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

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

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

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

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

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

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

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

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

Масштабирование экземпляров

Разрешения

Ограничения

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

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

Обратная связь

Дополнительные ресурсы