Настройка группы доступности Always On SQL Server в разных регионах Azure

Применимо к: SQL Server на виртуальной машине Azure

В этой статье описывается, как настроить группу доступности AlwaysOn SQL Server на виртуальных машинах Azure в удаленном регионе Azure. Эту конфигурацию можно использовать для поддержки аварийного восстановления.

Примечание

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

Данная статья относится к виртуальным машинам Azure в режиме Resource Manager.

На следующем рисунке показано типичное развертывание группы доступности на виртуальных машинах Azure.

Схема, показывающая подсистему балансировки нагрузки Azure и группу доступности с отказоустойчивой кластером Windows Server и группой доступности Always On

В таком развертывании все виртуальные машины находятся в одном регионе Azure. Реплики группы доступности могут использовать синхронную фиксацию с автоматической отработкой отказа на SQL-1 и SQL-2. Для создания этой архитектуры ознакомьтесь с шаблоном группы доступности или соответствующим руководством.

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

Аварийное восстановление группы доступности

На предыдущей схеме показана новая виртуальная машина с именем SQL-3. SQL-3 находится в другом регионе Azure. Она добавлена в отказоустойчивый кластер Windows Server. На SQL-3 можно разместить реплику группы доступности. Наконец, обратите внимание, что для региона Azure виртуальной машины SQL-3 используется новая подсистема Azure Load Balancer.

Примечание

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

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

Если реплики групп доступности находятся на виртуальных машинах Azure в разных регионах Azure, вы можете подключить виртуальные сети с помощью рекомендуемого пиринга между виртуальными сетями или VPN-шлюза "Сеть — сеть".

Важно!

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

Создание удаленной реплики

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

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

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

    Пиринг между виртуальными сетями. Подключение виртуальных сетей с помощью пиринга между виртуальными сетями на портале Azure (рекомендуется)

    или

    VPN-шлюз "Сеть — сеть". Настройка подключения между виртуальными сетями с помощью портала Azure.

    Примечание

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

  3. Создайте контроллер домена в новом регионе.

    Этот контроллер домена обеспечивает аутентификацию в случае, если контроллер домена на первичном сайте недоступен.

  4. Создайте виртуальную машину SQL Server в новом регионе.

  5. Создайте Azure Load Balancer в сети в новом регионе.

    Эта подсистема балансировки нагрузки должна:

    • находиться в той же сети и подсети, что и новая виртуальная машина;
    • использовать статический IP-адрес для прослушивателя группы доступности;
    • включать в себя внутренний пул, состоящий только из виртуальных машин, размещенных в том же регионе, что и подсистема балансировки нагрузки;
    • использовать пробу TCP-порта для IP-адреса;
    • использовать правило балансировки нагрузки для SQL Server в том же регионе.
    • являться подсистемой Load Balancer уровня "Стандартный", если виртуальные машины в серверном пуле не входят ни в отдельную группу доступности, ни в масштабируемый набор виртуальных машин. Дополнительные сведения см. в разделе Обзор Azure Load Balancer уровня "Стандартный".
    • являться подсистемой Load Balancer (цен. категория "Стандартный"), если две виртуальные сети в двух разных регионах являются одноранговыми посредством глобального пиринга виртуальных сетей. Дополнительные сведения см. в статье Виртуальная сеть Azure: часто задаваемые вопросы.
  6. Добавьте компонент отказоустойчивой кластеризации на новый сервер SQL Server.

  7. Присоедините новый сервер SQL Server к домену.

  8. Настройте новую учетную запись службы SQL Server для использования доменной учетной записи.

  9. Добавьте новый сервер SQL Server в отказоустойчивый кластер Windows Server.

  10. Добавьте ресурс IP-адреса в кластер.

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

    Снимок экрана: диспетчер отказоустойчивости кластеров с выбранным именем сервера имен кластера и выбранными свойствами.

    В диалоговом окне Свойства нажмите кнопку Добавить внизу поля IP-адрес, а затем добавьте IP-адрес имени кластера из удаленного региона сети. Нажмите кнопку ОК в диалоговом окне IP-адрес, а затем снова нажмите ОК в диалоговом окне Свойства кластера, чтобы сохранить новый IP-адрес.

    Добавление IP-адреса кластера

  11. Добавьте IP-адрес в качестве зависимости для имени основного кластера.

    Откройте свойства кластера еще раз и выберите вкладку Зависимости. Настройте зависимость ИЛИ для двух IP-адресов:

    Свойства кластера

  12. Добавьте ресурс IP-адреса в роль группы доступности в кластере.

    Щелкните правой кнопкой мыши роль группы доступности в диспетчер отказоустойчивости кластеров, выберите Добавить ресурс, Дополнительные ресурсы и IP-адрес.

    Создание IP-адреса

    Настройте этот IP-адрес следующим образом.

    • Используйте сеть удаленного центра обработки данных.
    • Назначьте IP-адрес из новой подсистемы Azure Load Balancer.
  13. Добавьте ресурс IP-адреса в качестве зависимости для кластера (сетевое имя) точки доступа клиента прослушивателя.

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

    Группа доступности

    Важно!

    Группа ресурсов кластера включает в себя оба IP-адреса. Оба IP-адреса являются зависимостями для точки доступа клиента прослушивателя. Используйте оператор OR в конфигурации зависимостей кластера.

  14. Настройте параметры кластера в PowerShell.

    Выполните сценарий PowerShell с сетевым именем кластера, IP-адресом и портом пробы, настроенными для подсистемы балансировки нагрузки в новом регионе.

    $ClusterNetworkName = "<MyClusterNetworkName>" # The cluster name for the network in the new region (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name).
    $IPResourceName = "<IPResourceName>" # The cluster name for the new IP Address resource.
    $ILBIP = "<n.n.n.n>" # The IP Address of the Internal Load Balancer (ILB) in the new region. This is the static IP address for the load balancer you configured in the Azure portal.
    [int]$ProbePort = <nnnnn> # The probe port you set on the ILB.
    
    Import-Module FailoverClusters
    
    Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}
    
  15. Включите группы доступности AlwaysOn на новом сервере SQL Server с помощью диспетчера конфигурации SQL Server.

  16. Откройте порты брандмауэра на новом сервере SQL Server. Номера портов, которые необходимо открыть, зависят от вашей среды. Откройте порты для конечной точки зеркального отображения и пробы работоспособности Azure Load Balancer.

  17. Настройте разрешения для системной учетной записи для новой платформы SQL Server в SQL Server Management Studio.

  18. Добавьте реплику в группу доступности на новом сервере SQL Server. Для реплики в удаленном регионе Azure настройте асинхронную репликацию с ручной отработкой отказа.

Настройка подключения для нескольких подсетей

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

Рекомендуется обновить конфигурацию кластера до значения RegisterAllProvidersIP=1 и строки подключения клиента до значения MultiSubnetFailover=Yes. Ознакомьтесь с разделом Соединение с помощью MultiSubnetFailover.

Если вам не удается изменить строки подключения, можно настроить кэширование разрешения имен. См. ошибку времени ожидания и невозможно подключиться к прослушивателю группы доступности SQL Server 2012 Always On в среде с несколькими подсетью.

Отработка отказа в удаленный регион

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

  1. В обозревателе объектов подключитесь к экземпляру SQL Server, на котором размещена первичная реплика.
  2. В разделе Always On группы доступности группы доступности щелкните правой кнопкой мыши группу доступности и выберите пункт "Свойства".
  3. На странице Общие в разделе Реплики доступности задайте для вторичной реплики на узле аварийного восстановления режим доступности Синхронная фиксация и автоматический режим отработки отказа.
  4. Если вторичная реплика находится на том же узле, что и первичная реплика, для обеспечения высокого уровня доступности, то задайте для нее режимы Асинхронная фиксация и Ручной.
  5. Нажмите кнопку "ОК".
  6. В обозревателе объектов щелкните правой кнопкой мыши группу доступности и выберите Show Dashboard (Показать панель мониторинга).
  7. На панели мониторинга убедитесь, что реплика на сайте аварийного восстановления синхронизирована.
  8. В обозревателе объектов щелкните правой кнопкой мыши группу доступности и выберите Отработка отказа… . В SQL Server Management Studio откроется мастер для отработки отказа SQL Server.
  9. Выберите Далее, а затем экземпляр SQL Server на сайте аварийного восстановления. Снова выберите Далее.
  10. Подключитесь к экземпляру SQL Server на сайте аварийного восстановления и нажмите кнопку Далее.
  11. Проверьте параметры на странице Сводка, а затем нажмите кнопку Готово.

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

Расположение Экземпляр сервера Роль Режим доступности Режим отработки отказа
Основной центр обработки данных SQL-1 Первичная Синхронная Автоматически
Основной центр обработки данных SQL-2 Вторичная Синхронная Автоматически
Дополнительный или удаленный центр обработки данных SQL-3 Вторичная Асинхронная Вручную

Дополнительные сведения о плановой и принудительной отработке отказа вручную

Дополнительные сведения см. в следующих разделах:

Дальнейшие действия

Дополнительные сведения см. на следующих ресурсах: