none
Разделение MS SQL 2012 кластера на два независимых MS SQL сервера. RRS feed

  • Вопрос

  • Добрый день коллеги.

    Суть такова.

    Есть кластер MS SQL 2012 из двух узлов построенный на Windows server 2012 r2, 2 кластерных диска + 1 общий кворум.

    Каждый узел выступает как active-pasive для своего инстанса. То есть в штатном режиме на ноде sqln1 активный инстанс inst1, на ноде sqln2 активный инстанс inst2. В случае отработки отказа, каждый из узлов может поднять на себя инстанс упавшего узла, и продолжить работу, после восстановления отказа каждый инстанс возвращается на предпочтительный для него узел.

    Необходимо с наименьшими временными затратами разобрать этот кластер на два независимых узла, так что бы в итоге на сервере sqln1 остался инстанс inst1, а на сервере sqln2 остался инстанс inst2.

    Как лучше это сделать? На сколько я понимаю статья https://technet.microsoft.com/ru-ru/library/ms191545.aspx мне тут не поможет, так как данная процедура удаляет сервер из кластера, а также и MSSQL с инстансом (или только MSSQL на этом узле?).

    Вся среда виртуализирована, если поднять новый сервер и переключить туда рабочие базы, планы обслуживания, а так же безболезненно (например с помощью DNS) переключить существующие соединения с MS SQL сервером, будет быстрее и надежнее разборки кластера то приемлем и этот вариант.

    Если я жестко привяжу кластерный диск к узлу + выключу отработку отказа для роли MS SQL сервера на узле, а потом его исключу из кластера, то что произойдет с сервером и инстансом?

    18 июля 2016 г. 14:32

Ответы

  • Доброго времени суток коллеги.

    Решил свой вопрос самостоятельно.

    Если кому будет интересно, то процедура перехода от cluster mssql в standalone mssql следующая.

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

    Все делал по данной статье https://blogs.msdn.microsoft.com/sqlserverfaq/2010/04/22/how-to-un-cluster-sql-server-2005-cluster за исключением некоторых свойственных моей среде нюансов. Большое спасибо человеку который написал эту статью. Изначально все сделал в тестовой среде, и после удачного эксперимента сделал в производстве. Сразу уточняю, что данный способ подойдет для тех, кто может остановить работу СУБД на 2-3 часа, зависит от размера бд (у меня суммарный размер баз был в районе 500гб для каждого сервера, время всего переноса заняло 3 часа). Если вы не можете на столько останавливать СУБД, то смотрите в сторону зеркалирования.

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

    • одинаковая архитектура SQL сервера (32-bit или 64-bit)
    • одинаковая редакция SQL сервера (SELECT SERVERPROPERTY(‘Edition’))
    • установлены одинаковые компоненты (Database Service, Reporting Services, Analysis Services…) были одинаковые пути каталогов баз данных и логов для всех системных и пользовательских баз.
    • одинаковое имя SQL инстанса (SELECT @@SERVERNAME)
    • одинаковый номер версии (SELECT SERVERPROPERTY(‘ProductVersion’)) 
    • Все скрипты и логины, которые использовались на кластерном SQL, имели доступы и работали на отдельном SQL сервере.
    • Сетевое имя SQL сервера и виртуальный IP адрес SQL сервера были одинаковые.

    Итак, что было сделано и в какой последовательности.

    1. Подготовлено 2 сервера, установлены все обновления, были добавлены жесткие диски для размещения каталога баз данных (системных и пользовательских), назначены этим дискам аналогичные буквы как на рабочих серверах. Сервера введены в домен, имена серверам были выбраны для удобства sql01-temp.domain.local и sql02-temp.domain.local, у рабочих серверов имена для MSSQL были соответственно sql01.domain.local и sql02.domain.local, IP адреса были назначены любые доступные.

    2. Каждый узел кластера был настроены так, чтобы не размещать на себе роли, диски и службы другого узла в кластере, то есть если узел или любой ресурс на узле sqln1 откажет, то не запускать эту роль\службу\диск на другом рабочем узле. Это необходимо сделать, что бы не возникали конфликты во время переноса данных с одного сервера на другой, так как необходимо будет останавливать MSSQL. И на всякий случай отключаем приоритет автозапуска для роли MSSQL. Сделать это можно все через оснастку управления кластером, раздел "Roles", далее выбираем нужное нам приложение, правой кнопкой мышки на нем в разделе "General" в "Preferred Owners" оставляем галку только на том узле, с которого собираемся переносить сервер MSSQL. Далее на вкладке "Failover" отключаем отказовозвращение, с помощью чекбокса "Prevent failback". Далее выбираем в нижнем окне оснастки в разделе "Roles" нажимаем на "Resources". Далее для каждого имеющегося ресурса (диск, имя и ip адрес сервера, службы mssql) настраиваем следующие параметры в настройках. Вкладка "Policies" - устанавливаем "If resource fails, do not restart". Вкладка "Advanced Policies - галочку ставим только напротив того узла, с которого собираемся переносить сервер MSSQL. Данные действия необходимо сделать для каждого ресурса.

    3. На узле который является пассивным для сервера MSSQL который собираемся переносить, запустить удаление узла для кластера MSSQL согласно данной статьи https://msdn.microsoft.com/en-us/library/ms191545.aspx#Remove, данное удаление необходимо для того, что бы на пассивном узле не оставалось никаких лишних хвостов от переносимого MSSQL сервера.

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

    5. Далее мы останавливаем все службы MSSQL сервера через оснастку управления "SQL Server Configuration Manager", и для каждой из служб выбираем тип запуска "Disabled". После того как мы остановим сервер, в оснастке управления кластером роль должна быть со статусом "Stopped", а службы "Offline".

    6. Теперь необходимо переименовать на узле виртуальное имя и виртуальный IP адрес для MSSQL сервера который переносим. Для этого в оснастке управления кластером, в разделе "Roles", далее выбираем MSSQL сервер который переносим, и в ресурсах этого приложения находим "Server name", жмем правой кнопкой на "Name", переводим данный ресурс в "Take Offline", далее заходим в настройки и меняем имя на вкладке "DNS Name:" на любое другое, например, на sql01-old. Нажимаем применить, далее на предупреждение нажимаем "Yes". После данного действие в Active Directory объект компьютера, будет корректно переименован с sql01 на sql01-old. Далее жмем правой кнопкой на "IP Address", переводим данный ресурс в "Take Offline", далее заходим в настройки и меняем "Static IP Address" на любой другой свободный IP адрес в этой же подсети, нажимаем применить и ок. Далее жмем правой кнопкой на "Name: sql02-old", и переводим в "Bring Online", после перехода в статус "Online", будет создана dns запись с измененными данными. Данное действие необходимо, чтобы избежать конфликта IP адресов, имени компьютера и dns имен.

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

    8. Если все так, то переименовываем и присваиваем новому подготовленному серверу имя сервера и ip адрес, которые были назначены виртуальному серверу в оснастке управления кластером. В нашем случае это sql02. После перезагрузки проверяем доступность нового сервера по ip адресу и dns имени, которое использовалось ранее для подключения к серверу SQL.

    9. Если все верно, то запускаем установку нового SQL сервера. Обязательно устанавливаем такую же версию и разрядность сервера, выбираем те же компоненты, которые использовались на кластерном экземпляре, указываем такой же путь каталога для баз, и выбираем те же учетные данные для запуска сервера. Кроме этого я создал такой же логин SA с тем же паролем как на кластерном SQL сервере, не уверен, что это нужно, так как будет заменяться полностью мастер база.

    10. После установки SQL сервера на новом сервере, мы сразу же останавливаем запущенные службы через оснастку управления "SQL Server Configuration Manager".

    11. Копируем с заменой всю директорию с системными базами с кластерного сервера в такую же директорию, и очень важно с той же буквой на новый сервер. В моем случае это было R:\MSSQL11.MSSQLSERVER2, и я копировал всю эту папку в такую же директорию на новом сервере. Рекомендую так же ознакомиться с данной статьей по поводу изменение каталогов для системных баз https://msdn.microsoft.com/ru-ru/library/ms345408.aspx.

    12. Далее, если ваш сервер был нестандартно настроен, а именно порты и т.д., то не забываем настроить это через "SQL Server Configuration Manager", в моем случае необходимо было указать порт подключения 1433, а также не забудьте настроить брандмауэр на сервере. Настройки брандмауэр windows можно экспортировать-импортировать.

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

    14. Запускаем все приложения, которые используют этот MSSQL, если все сделано верно, то они должны подключиться и начать использовать новый сервер без какого-либо вмешательства. Все мои приложения запустились и заработали корректно, а это базы 1С, RDS ферма, веб сайты, veeam, vmware, NPS, kaspersky, WSUS.

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

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


    8 августа 2016 г. 14:38