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

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

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

  1. Обновление операционной системы на сервере, где изначально развёрнута групп доступности AlwaysOn, не поддерживается.
  2. Если переносится группа доступности, SQL Server которой управляется кластером, потребуется новый узел WSFC для каждого узла FCI.
  3. Избегайте или минимизируйте ситуации, когда работа с базами данных будет происходить без обеспечения высокой доступности.
  4. Убедитесь, что у нового кластера правильно настроен режим обеспечения кворума и голосование узлов WSFC.
  5. Рекомендуется предварительно документировать исходную конфигурацию группы доступности в старом кластере.

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

Последовательность действий

  1. Если новый кластер ещё не существует, нужно его создать. Если новые узлы для нового кластера будут работать под управлением более новой версии операционной системы Windows, понадобятся новые серверы. Новых серверов должно быть не меньше двух (синхронная реплика и асинхронная). На каждом узле для нового кластера, на которых будут размещаться реплики доступности, должен быть установлен экземпляр SQL Server (либо отдельный, либо кластерный). Также, нужно установить для ОС функционал службы кластера. После включения сервера в число узлов кластера, в менеджере конфигурации этих экземпляров нужно включить у службы MSSQLSERVER поддержку групп доступности AlwaysON. Чтобы создать новый кластер и использовать в нём некоторые из существующих узлов старого кластера, потребоваться исключить эти узлы из исходного кластера. Перед этим с этих узлов нужно удалить все реплики доступности. После включения этих серверов в новый кластер, их можно использовать в качестве дополнительных, асинхронных реплик. Таким образом, можно обойтись только одним дополнительным сервером или вообще без таковых.
  2. В новом кластере нужно переключить контекст HADR каждого нового экземпляра с LOCAL на имя старого кластера. LOCAL тут указывает на текущий кластер (новый), в который до этого сервер был добавлен.
  3. Новые серверы нужно добавить в группу доступности, синхронизировать и подключить как вторичные реплики. Если есть только один новый сервер, то после подключения его в качестве синхронной реплики к группе доступности старого кдастера, можно убрать из этой группы реплику в старом кластере, вывести её из старого и ввесли в новый кластер и потом добавить в группу доступности в качестве дополнительной асинхронной реплики, необходимой для обеспечения высокой доступности в процессе миграции.
  4. В старом кластере нужно будет подключиться к экземпляру сервера, на котором размещена первичная реплика, и удалить прослушивателя группы доступности и перевести группу доступности в режим «вне сети». Если группу доступности на старом сервере просто удалить, а не отправить в офлайн, базы группы окажуться в онлайне, а не в Restoring.
  5. В новом кластере нужно переключить контекст HADR каждого нового экземпляра в LOCAL. После этого становиться возможным создание группы доступности в новом кластере.
  6. Нужно будет подключиться к тому новому экземпляру, на котором размещается реплика с синхронной фиксацией, и там заново создать группу доступности, используя ее исходное имя. После этого там же создать прослушивателя для группы доступности, используя его первоначальные VNN и VIP. Чтобы повторно использовать тот же VNN, необходимо предварительно подготовить к этому Active Directory. Поскольку удаление прослушивателя из старого кластера не приводит к удалению его компьютерного объекта VNN из Active Directory, чтобы новый кластер смог снова использовать его VNN, новому кластеру нужно предоставить полные права на управление объектом VNN прослушивателя группы доступности. Конечные точки подключения (Hadr_endpoint) должны допускать подключение учётной записи запуска службы SQL Server нового первичного сервера и учётных записей учавстующих в группе доступности компьютеров. Учитывайте, что после изменения наборов прав объектоа AD может потребоваться время на их актуализацию всех доменных контроллеров, куда насроена репликация.

Рисунок 1. Процесс миграции ресурсов для группы доступности AG1

План миграции

  1. По возможности, чтобы высвободить аппаратные ресурсы и минимизировать работы во время простоя, исключите избыточные узлы из старого кластера WSFC. Предварительно нужно удалить или переместить любые реплики доступности, размещенные на удаляемых из старого кластера узлах.
  2. Создайте новый кластер WSFC.
  3. Установите экземпляр SQL Server на каждом узле нового кластера. Каждый узел может содержать только один экземпляр SQL Server с поддержкой AlwaysOn.
  4. Для экземпляров сервера в новом кластере включите поддержку групп доступности AlwaysOn.
  5. Убедитесь, что выполнены рекомендации для групп доступности AlwaysOn. Оба кластера должны быть в рабочем состоянии и не иметь проблем с доступностью включённых в них ресурсов.
  6. На каждом узле старого кластера предоставьте разрешение на ветку реестра кластера «HKLM:\Cluster» учетной записи служб SQL Server, от и имени которых запускаются экземпляры в новом кластере.  Для этого на первичном сервере выполните следующую команду PowerShell, используя прикреплённый в конце статьи команлет (заменив в следующем примере newserverserviceaccoun на имя сервисной учётки нового сервера):

    .\AclClusterPermission.ps1 -Action add -Account

  7. Если в старом кластере ичпользутся кворум-диск: сервер с подключенным кворум-диском нужно дать права локального администратора учетной записи домена, из под которого стартует служба MSSQLServer.
  8. Предоставьте новому кластеру полный доступ в Active Directory к компьютерному объекту VNN переносимого прослушивателя группы доступности.
  9. На новых серверах переключаем HADR Cluster Context c локального (LOCAL) на контекст старого кластера: ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT ={ ‘ windows_cluster ‘ }
  10. На серверах нового кластера нужно создать реплики баз данных группы доступности, синхронизировать и подключить базы к группе доступности. Когда вы добавляете вторичные реплики в группу доступности, лучше не разрешайте на них чтение и не используйте их для резервного копирования.
  11. Синхронизировать базы данных (путём восстановления резервных копий) на новых серверах с базами данных группы доступности.
  12. Добавить новые реплики в группу доступности, одну в синхронном и одну в асинхронном режиме фиксации транзакций.
  13. Удаляем прослушивателя группы доступности. ВНИМАНИЕ! Это важно сделать до перевода группы доступности в офлайн. С этого момента пользователи не смогут подключаться к базам через прослушивателя. Что бы облегчить дальнейший процесс миграции можно очтановить задаиня по расписанию, который вносят изменения в базах группы доступнсти и делают копии журналов транзакций этих баз (в идеале, можно остановит службу агента SQL Server).

    ALTER AVAILABILITY GROUP [AG1] REMOVE LISTENER N’AG1-listiner’
    GO

  14. Останавливаем работу кода, который может вносить изменения в данные (SSIS – пакеты, задания Jobs и т.п.). Дожидаемся полной синхронизации данных.
  15. Переводим группу доступности во вне сети (offline).

    ALTER AVAILABILITY GROUP AG1 OFFLINE
    GO

  16. Переключаем HADR Cluster Context нового первичного сервера на локальный (LOCAL):
    ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT = LOCAL
    После этого, на новых серверах группа доступности исчезнет.
  17. После синхронизации реплики на новом первичном сервере, где у нас была реплика с синхронной фиксации, выполняем для её баз данных RECOVERY. Пока пользователи ещё не начали работать с базами, в этот момент нужно выполнить все настройки баз, которые сложно или невозможно сделать под нагрузкой. Нужно где нужно включить Service Broker, создать и/или открыть мастер – ключи и т.п. Например:

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘PASSWORD’;
    ALTER DATABASE [DATABASENAME] SET ENABLE_BROKER WITH NO_WAIT;
    ALTER DATABASE [DATABASENAME] SET TRUSTWORTHY ON;

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

  18. Далее, нужно обеспечить возможность и права для подключения к конечным точкам:
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
    GO
    GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOMAINNAME\SEVICEDOMENUSERNAME]
    GO
    IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name=’AlwaysOn_health’)
    BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
    END
    IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name=’AlwaysOn_health’)
    BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
    END
    GO

  19. Создаём группу доступности на основании баз данных нового сервера, базы которого к этому времени доступны для подключений пользователей.
    CREATE AVAILABILITY GROUP [AG1]
    WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE)
    FOR DATABASE [DATABASENAME]
    REPLICA ON N’NEWPRIMARYSQLSERVER’
    WITH (ENDPOINT_URL = N’TCP://NEWPRIMARYSQLSERVER.ru:5022′
    ,FAILOVER_MODE = MANUAL
    ,AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
    ,BACKUP_PRIORITY = 50
    ,SEEDING_MODE = MANUAL
    ,SECONDARY_ROLE(READ_ONLY_ROUTING_URL = N’TCP://NEWPRIMARYSQLSERVER.ru:1433′
    , ALLOW_CONNECTIONS = ALL))
    GO

  20. Синхронизируем и подключаем к мигрировавшей группе доступности вторичную реплику на новом сервере, где был асинхронный режим.
  21. Добавляем прослушивателя к группе доступности, используя оригинальное имя VNN и VIP.
    ALTER AVAILABILITY GROUP [AG1]
    ADD LISTENER N’AG1-listiner’ (
    WITH IP
    ((N’10.21.5.143′, N’255.255.255.0′)
    ), PORT=1433);
    GO

  22. Если группа доступности объединяет сервера из разных подсетей, нужно обеспечить присутствие в сети только одного IP – адреса листенера. Для этого выполните сценарий Powershell, который обеспечит присутсвие в сети только того адреса, который в одной подсети с адресом сервера первичной реплики, а адрес из другой подсети будет вне сети:
    Import-Module FailoverClusters
    Get-ClusterResource AG1-listiner | Set-ClusterParameter RegisterAllProvidersIP 0
    Get-ClusterResource AG1-listiner | Set-ClusterParameter HostRecordTTL 60
    Stop-ClusterResource AG1-listiner
    Start-ClusterResource AG1-listiner 

    Как это описано в статье: Настройка прослушивателя для группы доступности Always On. Актуальное имя кластерного ресурса листенер можно узнать, запустив на сервере нового кластера без параметров командлет:

    Get-ClusterResource

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

  23. Добавляем дополнительные реплики, по необходимости.

Дополнительные материалы:

  1. Cross-cluster Migration of AlwaysOn Availability Groups for Operating System Upgrades
  2. SQL SERVER – Unable to Create Listener: Msg 41009 – The Windows Server Failover Clustering (WSFC) Resource Control API Returned Error Code 5057
  3. AclClusterPermission.zip

Абривеатуры

Сокращение Описание
FCI SQL Server failover cluster instance
HA High availability
VIP Virtual IP address
VNN Virtual network name
WSFC Windows Server Failover Clustering

Благодарности

Спасибо моим коллегам Александру, Борису, Илье и Никите за помощь в написании статьи.