Перенос экземпляра SQL Server 2012 на другой диск в кластере Windows Server 2012 R2

Имеется двух-узловой кластер Windows Failover Cluster из двух виртуальных машин Hyper-V c гостевой ОС Windows Server 2012 R2. В кластере развёрнуто несколько высоко-доступных экземпляров SQL Server 2012 SP3. Каждый кластерный экземпляр SQL Server расположен на выделенном кластерном диске. Возникла необходимость переноса экземпляров SQL с одного кластерного диска на другой с последующим отключением ранее используемого кластерного диска. В этой заметке будет пошагово рассмотрена процедура данного переноса на примере отдельно взятого кластерного экземпляра SQL Server.

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

1. Подключаем новый LUN к узлам кластера
2. Инициализируем LUN и форматируем новый раздел NTFS
3. Добавляем новый диск в кластер Failover Cluster
4. Снимаем рабочую нагрузку с экземпляра SQL Server
5. Добавляем дисковый ресурс к кластерной роли SQL Server
6. Выполняем частичную остановку кластерной роли SQL Server (останавливаем Имя и Службы)
7. Копируем файлы экземпляра SQL Server на целевой кластерный диск (robocopy)
8. Изменяем буквы кластерных дисков
9. Изменяем дисковую зависимость кластерного ресурса SQL Server
10. Запускаем кластерную роль SQL Server
11. Проверяем доступность экземпляра SQL Server
12. Выполняем проверочную миграцию кластерной роли SQL Server между узлами кластера
13. Возобновляем рабочую нагрузку на экземпляр SQL Server
14. Удаляем из кластера старый диск
15. Отключаем LUN старого диска от виртуальных машин

Рассмотрим все шаги по порядку.

Шаг 1. Подключаем новый LUN к виртуальным машинам

В нашем случае LUN-ы с СХД пробрасываются в виртуальные машины через FC SAN посредствам технологии NPIV. Поэтому первым делом нам нужно презентовать дополнительный новый LUN на оба узла кластера Windows Failover Cluster, то есть на обе виртуальные машины на базе гипервизора Hyper-V в Windows Server 2012 R2. Описывать то, как это делается не будем, так как это зависит от используемой инфраструктуры FC SAN, моделей коммутаторов и СХД. В конечном итоге на каждом из наших виртуальных серверов в оснастке Device Manager мы должны увидеть новые дисковые устройства

Если LUN подключен к серверу по нескольким путям, то проверяем доступность всех путей на вкладке MPIO в свойствах подключенного дискового устройства. Запомним Location нового диска, так как он нам может пригодится на следующем шаге (справедливо, когда подключается множество однообразных дисков).

Шаг 2. Форматируем новый раздел NTFS

Так как LUN подключен к обоим серверам, выполнить инициализацию и форматирование нового диска можно на любом из этих серверов. Я предпочитаю предварительно мигрировать все кластерные роли на один из серверов и выполнять процедуру настройки нового диска на свободном узле кластера. Откроем оснастку Disk Management и по Location найдём интересующий нас новый диск. Сначала переведём диск в Online, затем выполним его инициализацию – Initialize Disk

В процессе инициализации диска будет создана таблица разделов.

После того, как диск будет проинициализирован, создаём на нём новый раздел.

Для создаваемого раздела выберем букву диска, которая не используется ни на одном из узлов кластера. Условимся, что это будет том X:. В качестве файловой системы укажем NTFS, а также зададим понятную метку тома, чтобы легче в дальнейшем идентифицировать наш диск.

Теперь созданный логический диск нужно подключить к кластеру Windows Failover Cluster.

Шаг 3. Добавляем новый диск в кластер Failover Cluster

В оснастке Failover Cluster Manager подкачаемся к кластеру, содержащему кластерную роль высоко-доступного экземпляра SQL Server и в разделе Storage > Disks вызываем пункт добавления нового диска Add Disk. В открывшемся поверх окне выбираем ранее отформатированный нами диск:

Диск появится в консоли с типом Available Storage, то есть в данный момент он не привязан ни к какой кластерной роли.

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

Шаг 4. Снимаем рабочую нагрузку с экземпляра SQL Server

На данном этапе мы должны снять всю продуктивную нагрузку на наш кластерный экземпляр SQL Server, то есть выключить все приложения и службы, которые могут обращаться к базам данных экземпляра. В нашем примере выполняется перенос экземпляра SQL Server, в котором размещаются базы данных, используемые в работе сервера Microsoft System Center Configuration Manager (SCCM). Таким образом на данном шаге на сервере SCCM мы останавливаем все службы, которые используют обращение к базам данных SQL Server.

Шаг 5. Добавляем дисковый ресурс к кластерной роли SQL Server

В оснастке Failover Cluster Manager переходим а раздел управления кластерными ролями (Roles), в списке доступных ролей выбираем целевой кластерный экземпляр SQL Server и в меню действий вызываем пункт добавления дискового ресурса - Add Storage.

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

После этого в перечне ресурсов кластерной роли SQL Server появится новый дисковый ресурс.

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

Шаг 6. Выполняем частичную остановку кластерной роли SQL Server

В перечне ресурсов кластерной роли выбираем ресурс с именем кластера Name:<Имя кластера> и в меню действий вызываем пункт выключения ресурса – Take Offline.

После этого будут остановлены ресурсы службы экземпляра SQL Server (<Имя экземпляра>) и агента SQL Server Agent (<Имя экземпляра>). А сама кластерная роль изменит статус на Partially Running.

Соответствующие указанным кластерным ресурсам системные службы SQL Server (<Имя экземпляра>) и SQL Server Agent (<Имя экземпляра>), относящиеся к нашему экземпляру SQL Server будут остановлены. Убедиться в этом можно проверив состояние служб в оснастке управления службами Services и/или оснастке SQL Server Configuration Manager.

Шаг 7. Копируем файлы экземпляра SQL Server на целевой кластерный диск

Частичная остановка кластерной роли с нетронутыми дисковыми ресурсами роли позволит нам выполнить любые файловые операции с файлами экземпляра SQL Server, так как теперь эти файлы не блокируются системными службами экземпляра. В нашем примере файлы остановленного кластерного экземпляра SQL Server размещены в каталоге MSSQL11.SCCM на диске S: и нам нужно  скопировать этот каталог на новый кластерный диск X:. 

Для правильного полноценного копирования всех атрибутов файлов и разрешений безопасности, установленных на всех вложенных каталогах и файлах, воспользуемся утилитой robocopy (команду выполнять, запустив консоль от имени Администратора):

ROBOCOPY "S:\MSSQL11.SCCM" "X:\MSSQL11.SCCM" /E /B /COPYALL /DCOPY:DAT /V /R:2 /W:10 /UNILOG+:X:\MSSQL11.SCCM.log /BYTES /TEE /NP /UNICODE

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

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

Шаг 8. Изменяем буквы кластерных дисков

Так как конфигурация остановленного экземпляра SQL Server хочет видеть свои файлы в каталоге S:\MSSQL11.SCCM, нам потребуется выполнить замену букв дисков, таким образом, чтобы буква S: была присвоена вновь подключенному диску, на который мы только что скопировали файлы экземпляра. А старому диску мы присвоим текущую букву нового диска (X:). То есть фактически мы должны поменять местами буквы старого и нового диска. 

Чтобы букву диска S: можно было присвоить новому диску, эту букву нужно освободить, то есть снять её со старого диска. Для этого в оснастке Failover Cluster Manager и в области управления ресурсами кластерной роли выбираем старый диск и в меню действий вызываем пункт смены буквы диска – Change Drive Letter. В окне выбора буквы диска выбираем вариант <none> и сохраняем изменения.

Теперь буква диска S: свободна и мы назначаем её на новый диск.

После этого старому диску присваиваем освободившуюся букву X:

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

Шаг 9. Изменяем дисковую зависимость кластерного ресурса SQL Server

Среди ресурсов кластерной роли SQL Server в конфигурации по умолчанию только один ресурс имеет зависимость от кластерного диска – это ресурс службы экземпляра с именем SQL Server (<Имя экземпляра>). Откроем свойства этого ресурса и на закладке зависимостей Dependencies из выпадающего списка вместо старого кластерного диска выберем новый диск. Сохраним изменения.

Теперь всё готово к запуску кластерной роли.

Шаг 10. Запускаем кластерную роль SQL Server

Пробуем запустить ресурс службы экземпляра с именем SQL Server (<Имя экземпляра>), выбрав в меню действий Bring Online. При запуске этого ресурса автоматически должен быть запущен зависимый ресурс с именем кластера Name:<Имя кластера>.

После этого аналогичным образом запускаем кластерный ресурс агента SQL Server Agent (<Имя экземпляра>).

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

Шаг 11. Проверяем доступность экземпляра SQL Server

Проверяем статус системных служб SQL Server в оснастках управления службами Services или SQL Server Configuration Manager. Пробуем подключиться к экземпляру, например с помощью консоли SQL Server Management Studio. Если всё хорошо, переходим к проверке успешности миграции кластерной роли между узлами кластера.

Шаг 12. Выполняем проверочную миграцию кластерной роли SQL Server

Выполняем проверочную передачу кластерной роли SQL Server на второй узел кластера и обратно. Сделать это можно как с помощью оснастки Failover Cluster Manager , так и с помощью PowerShell:

Get-ClusterGroup "<Имя кластерной роли>" | Move-ClusterGroup

Если миграция кластерной роли нашего высоко-доступного экземпляра SQL Server работает успешно, можем возобновлять продуктивную нагрузку на экземпляр.

Шаг 13. Возобновляем рабочую нагрузку на экземпляр SQL Server

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

Шаг 14. Удаляем из кластера старый диск

В оснастке Failover Cluster Manager в области управления ресурсами кластерной роли выбираем старый кластерный диск (он теперь с буквой X:) и в меню действий вызываем команду его извлечения из кластерной роли -  Remove from SQL Server (<Имя экземпляра>).

После этого переходим в раздел управления дисками кластера (Storage > Disks) и удаляем старый диск, имеющий теперь статус Available Storage.

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

Шаг 15. Отключаем LUN старого диска от виртуальных машин

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

Дополнительные источники информации:

Justin's IT Blog - How-To: Migrate MS SQL Cluster to a New SAN