Приветствую всех.
В данной статье я опишу свой опыт по преобразованию «железного» кластера MSCS в виртуальный сервер.
Наш кластер работал с 2008 года, задач накопилось много, в том числе критических, а поднять новый сервер было нереально. К тому же износившееся оборудование вот-вот должно было выйти из строя. Для нас выход был только один – виртуализация сервера в наш ЦОД, на VMware. Причем для меня была поставлена задача — уйти от кластеризации. Изучив кучу информации в сети, подходящей пошаговой инструкции я не нашел, поэтому решил составить свою.
Исходное состояние было следующее:
- Кластер MSCS на Windows 2003 Enterprise edition SP2. Две ноды в режиме ActivePassive;
- SQL Server 2005 Standard Edition, работающий в кластерном режиме;
- Несколько WWW/FTP-сайтов на IIS, не в кластерном режиме. На каждый из 32 Web-сайтов по одному IP Address кластерному ресурсу. Грубо говоря, на сетевую карту навешивались дополнительные IP. Сайты работали только в интрасети;
- 9 логических дисков с данными, 152 File Share ресурсов, все данные хранятся на дисковом массиве;
- Настроенный планировщик задач, через него запускались некоторые специфические для нашей отрасли программы.
Для предварительной подготовки и тестирования сервера мы создали виртуальную «лабораторию».
В изолированную виртуальную сеть мы подключили три машины: виртуальная копия активной ноды кластера, виртуальная копия контроллера домена и обычная машина с Windows 7, на которой мы все будем тестировать. Заранее были сконвертированы в VMDK несколько дисков с базами SQL, www/ftp-сайтами, сетевыми папками, кворум диск.
Запускаем машины, настраиваем сетевые карты с такими же TCP/IP параметрами, как и в реальной сети. Подключаем диски к нашему серверу, назначаем соответствующие буквы, перезагружаемся. После этого кластер должен запуститься. Кстати говоря, в режиме одной ноды кластер сразу заработал, но нам он больше не нужен, тем более есть риск, что такая конфигурация будет работать некорректно в виртуальной среде.
Теперь нужно сохранить настройки сетевой карты и параметры сетевых ресурсов, т.к. после удаления кластерной службы их придется восстанавливать вручную. Я предварительно подготовил dump TCP/IP настроек при помощи команды netsh. Сетевые ресурсы я планировал создавать заново, командой «net share». Возможно, есть способ сделать бэкап настроек сетевых шар, но я его не нашел.
Итак, у нас есть файл ip.cfg и shares.txt(список команд net share). Делаем Snapshot, для того чтобы откатиться назад в случае неудачи.
Начинаем декластеризацию
- После запуска виртуальной копии второй узел кластера будет уже недоступен. Удаляем его командой Evict Node.
Может возникнуть такое сообщение, тут без вариантов, нажимаем ОК.
- Далее настраиваем SQL. Нам нужно, чтобы он запускался в обычном режиме. В инструкциях, найденных в интернете, предлагают делать копии баз данных, удалять кластеризованный Instance, потом устанавливать Standalone Instance. Я нашел способ проще, через реестр:
Удаляем веткиHKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL.1Cluster
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL.2Cluster
Изменяем ключи
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL.1SetupSqlCluster = 0
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQL.2SetupSqlCluster = 0
В SQL Server configuration manager ставим сервисы на автозапуск.
- Включаем службы WWW Publishing Service, Task Scheduler на автозапуск. Раньше они запускались вручную только на активной ноде.
- Удаляем последнюю ноду из кластера. После этого такие кластерные ресурсы как IP address и File Share удаляются из системы безвозвратно.
- Чтобы пользователи потом смогли нормально работать с сетевыми папками, снова делаем правку реестра:
В разделе реестра HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanServerParameters
добавляем параметр DWORD «DisableStrictNameChecking», со значением 1
- Восстанавливаем настройки сети:
Netsh exec c:ip.cfg - Восстанавливаем сетевые ресурсы из текстового файла shares.txt. Просто копируем команды и вставляем в cmd. Я пробовал сделать bat-ник, но там возникала проблема с отображением русских символов в описаниях ресурсов.
- Перезагружаем сервер. После этого проверяем работу всех ftp-, www-, share-ресурсов в нашей лаборатории.
Если все в порядке, значит виртуальный сервер готов к переходу в обычную сеть.
Вкратце о переходе
Нюансы здесь могут быть разные, но принцип один: нужно отключить железный кластер, перенести ресурсы и настройки на новый сервер и включить его. В моем случае ресурсы – это IP-адреса, логические диски с данными, сетевые шары.
Мы не стали полностью удалять железный кластер из сети и AD, чтобы в случае неуспеха можно было все вернуть обратно.
Наши действия:
- Отключаем от сети и от дисков железный кластер. IP адреса освобождаются.
- Общий объем данных — 1,5 Тб, поэтому перевести сразу все диски в VMDK не получится, информация постоянно обновляется. Мы решили временно подключить их к виртуальному серверу как RDM, тем самым уменьшив время простоя во время перехода. Как показал опыт, лучше подключать их на выключенную машину. После запуска, на эти диски нужно назначить такие же буквы как на старом кластере, у нас, например, базы SQL-сервера запускались с диска S.
- Включаем виртуальный сервер в общую сеть, перезагружаем.
После перезагрузки корректно заработали FTP, WWW сервисы, SQL. На все действия ушло чуть меньше часа.
Некоторое время спустя появился глюк с сетевыми шарами, когда некоторые пользователи не могут зайти на них по старому имени кластера. Возможные варианты исправления:
- Проверить исполнение пункта 5 инструкции.
- Удалить старые записи на WINS-сервере для кластерного имени
- При развертывании кластера MSCS, в AD кроме учетных записей первой и второй ноды, создается третья учетная запись с именем кластера: ее описание — «Server cluster virtual network name account». Этой учетке нужно сделать disable.
- В DNS сделан алиас по имени кластера на первую ноду.
В настоящий момент виртуальный сервер работает исправно. Никаких глюков не наблюдается. Теперь можно спокойно отпраздновать Новый Год версии 2015. Всем спасибо за внимание.
Автор: superdzen
