Миграция виртуальных машин с платформы ESXi 4.1 на платформу виртуализации XenServer 6.2

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

В этой статье будет рассмотрена поэтапная миграция виртуальных машин с гипервизора VMWare ESXi 4.1.0 на гипервизор XenServer 6.2.

Citrix XenServer зарекомендовал себя как надежное и проверенное решение корпоративного класса, позволяющее организациям с самыми разными масштабами и бюджетами ощутить все преимущества серверной виртуализации.

Всем уже известно, что компания Citrix представила новую платформу виртуализации XenServer 6.2 и перевела ее в категорию Open Source. Такие возможности как Live Storage Migration, High availability, GPU passthrough и т.п., которые были доступны только в коммерческих версиях XenServer’а, теперь стали бесплатны. Подробнее можно прочитать тут.

Так как Citrix прекратила поддержку продукта  XenConvert, то начиная с версии XenServer 6.2 P2V-миграция виртуальных машин посредством этого решения стала невозможной. Воспользуемся продуктом XenServer Conversion Manager. 
XenServer Conversion Manager не поддерживает конвертацию виртуальных машин, если на гипервизоре esxi активирована бесплатная лицензия.

Для того чтобы произвести миграцию, необходимо обновить гипервизор ESXi 4.1 до ESXi 5.1.

Это дает возможность использовать максимальную лицензию VMware vSphere Enterprise Plus бесплатно в течении пробного периода 60 дней.

Приступим к обновлению ESXi 4.1 до ESXi 5.1.

Удаляем с виртуальных серверов VmWare Tools.

Выключаем виртуальные машины.

Перезагружаем сервер ESXi 4.1 и загружаемся с установочным диском ESXi 5.1

Выбираем ESXi-5.1.0-20130402001-standard installer и нажимаем «Enter»

Начнется подготовка к установке.

Видим окно приветствия, нажимаем Enter.

Принимаем EULA, нажав F11.

Выбираем необходимый том для установки и нажимаем «Enter».

Выбираем «Upgrade ESXi, preserve VMFS datastore» и нажимаем «Enter».

Подтверждаем обновление, нажав «F11»

Начнется обновление ESXi 4.1 до ESXi 5.1.

 

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

Подключаемся к хосту виртуализации посредством «vSphere client» и видим, что обновление прошло успешно.

Коллеги, не забываем про резервное копирование перед обновлением!

Подготавливаем площадку для конвертации виртуальных машин с ESXi 5.1 на XenServer 6.2.

Заходим на www.citrix.com/downloads, качаем виртуальную машину XenServer Convertion Manager Virtual Appliance и консоль управления XenServer Convertion Manager Console.

Подключаемся к хосту виртуализации XenServer посредством «Citrix XenCenter» и импортируем «XenServer Convertion Manager Virtual Appliance».

Нажимаем правую кнопку мыши на хосте и в контекстном меню выбираем «Import».

Указываем путь до XVA файла, нажимаем «Открыть». 

Выбираем соответствующий XenServer для импорта, в нашем случае «XenServer 6.2», нажимаем «Next»

Выбираем необходимый Сторадж репозиторий и нажимаем «Import»

Указываем соответствующий сетевой интерфейс, нажимаем «Next»     

Нажимаем «Finish», начнется импорт виртуальной машины.

После успешного импорта, приступим к конфигурированию виртуальной машины «Citrix XCM Virtual Appliance»

Далее поправим файл «convsvc.exe.config»: nano /opt/citrix/conversion/convsvc.exe.config

<add key="ConversionServer.IP" value="192.168.0.116" />

Где 192.168.0.116 – IP адрес «Citrix XCM Virtual Appliance»

Устанавливаем «XenServer Conversion Manager Console» на Windows машину.

Запускаем консоль, нажимаем «Connect», вводим IP адрес и учетные данные XenServer’а, в нашем случае «192.168.0.115»

Нажимаем «Convert» и вводим IP адрес и учетные данные ESXi 5.1, после чего «Connect».

Выбираем необходимый Сторадж Репозиторий, нажимаем «Next»

Далее выбираем виртуальную машину, нажимаем «Next». В нашем случае «1С»..

Выбираем соответствующий сетевой интерфейс, нажимаем «Next»

Сверяем, что все ли указано корректно и нажимаем на «Finish»

Начнется миграция виртуальной машины с ESXi 5.1 на XenServer 6.2

После окончания конвертирования, запускаем виртуальную машину «1С».

Посредством консоли «Citrix XenCenter» заходим на сервер «1С», устанавливаем «XenTools» и перезагружаемся.

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

Запускаем командную консоль «cmd», вводим:

set devmgr_show_nonpresent_devices=1
cd\%SystemRoot%\System32
start devmgmt.msc

Откроется диспетчер устройств. Во вкладке «View» выбираем «Show hidden devices».

Удаляем ненужные устройства.

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

На этом предлагаю закончить.

Вопросы, замечания и предложения пишите в комментариях или на почту.

Удачного тестирования!

Настройка AlwaysOn на MS SQL2012 без общего хранилища.

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

В этой статье рассмотрим настройку групп доступности AlwaysOn на сервере MS SQL 2012 в связке с сервером 1С Предприятие 8.2. Что такое AlwaysOn можно прочитать в официальной документации тут. 

Ни для кого не секрет, что для работы нормальной работы MS SQL нужна нормальная дисковая подсистема, с хорошим контроллером и быстрыми дисками. Ибо на каждый запрос SQL сервер взаимодействует (запись/чтение) сразу с четырьмя файлами БД: tempdb.mbf и templog.ldf, base.mbf и base.ldf. Не трудно догадаться, что в отчетные периоды, при высоких транзакциях, производительность дисковой подсистемы, а в следствие и SQL, падает.

Статья расскажет, как можно увеличить производительность работы MS SQL 2012, не в ущерб отказоустойчивости, используя группы доступности AlwaysOn. Для тестирования производительности возьмем программный продукт 1С Предприятие, т.к. при больших проводках сервер сильно грузит базу tempdb. В качестве тестируемой конфигурации будем использовать тест Гилева.

Группы доступности AlwaysOn не требуют общего хранилища для баз данных, поэтому можно приобрести несколько SSD дисков, собрать их в Raid 0 и разместить там БД. А резервный SQL (реплику) и прочие ресурсы будут находиться на удаленном хранилище. Тем самым мы повысим скорость дисковой подсистемы за счёт SSD, и увеличим отказоустойчивость и доступность баз данных, за счёт реплики, при выходе из строя дисков SSD.

Воспользуемся следующим планом:

1. Установка кластера WSFC Windows Server.
2. Установка SQL Server 2012 на каждом узле кластера. Создание и настройка групп обеспечения доступности AlwaysOn.
3. Добавление баз данных 1С в группу доступности
4.  Проверка работоспособности, имитируя отказ основного сервера.

Для работы Группы доступности AlwaysOn требуется развернуть WSFC-кластер. Именно WSFC-кластер следит за доступностью узлов и экземпляров SQL. Кластер WSFC требует наличие общей внешней сетевой папки, где будет находиться Quorum. На каждом узле кластера необходимо установить SQL сервер. Клиентская программа будет подключаться к WSFC-кластеру, видя его как отдельный инстанс SQL.

Подробнее про WSFC-кластер можно прочитать тут. 

Устанавливаем WSFC-кластер.

Запускаем «Диспетчер сервера» и добавляем компоненту «Failover Clustering»:

Перед созданием кластера, советую протестировать правильность всех настроек. Открываем «Failover Cluster Manager console», запускаем «Validate a configuration»:

Добавляем имена тестируемых серверов:

Проверяем результат и исправляем возникшие проблемы:

После исправления всех проблем, приступаем к созданию кластера.

Нажимаем «Create a Cluster», добавляем нужные нам сервера (dbsql01.test.local и dbsql02.test.local) и указываем имя кластера dbclt01.test.local.

 Создаем кластер.

Добавляем кворум.

Щелкаем правой кнопкой мыши на имя кластера и выбираем «More Action->Configure Cluster Quorum Settings»

Выбираем «Node and File Share Majority».

Указываем сетевую папку для Quorum’а и нажимаем Finish.

Приступим к настройке и установке SQL сервера.

Описание установки можно пропустить, т.к. процесс прост и тривиален. Будем использовать инстанс по умолчанию.

После установки, открываем SQL Server Configuration Manager, в меню SQL Server Services переходим к свойствам SQL (MyInstance) и ставим галку напротив AlwaysOn High Availability.

Проделываем данную процедуру на каждом SQL сервере.

Перезапускаем службу.

Открываем SQL Server Management Studio, подключаемся к серверу и создаем базу данных Test_db, указывая модель восстановления full. Делаем полный бэкап базы. Это необходимое условие.

 

Обратите внимание, что группы доступности будут работать с любым параметром Compatibility level.

Создаем новую группу доступности, щелкнув правой кнопкой мыши по AlwaysOn High Availability и перейдя в New Availability Group Wizard..

Присваиваем имя группе Test_group_1

Добавляем нашу базу.

Добавляем сервер с общим хранилищем dbsql02.test.local: нажимаем на Add Replica и подключаемся к серверу.

Устанавливаем необходимые галочки. В нашем случае это:

Переходим во вкладку Listener и производим соответствующую настройку:

Указываем метод синхронизации «Full» и прописываем путь к сетевой папке. Произойдет полное резервное копирование на шару и восстановление базы на сервер dbsql02.test.local.

После проверки начнется синхронизация базы и создание группы доступности.

Заходим в менеджмент консоль, видим группу доступности Test_group_1 и защищенную базу данных Test_db с пометкой «Synchronized».

Теперь подключаемся к кластеру WSFC dbclt01.test.local

Видим, что в кластере база Test_db также доступна.

Проверяем работоспособность. 

Создим таблицу и заполним ее.

 CREATE TABLE Dzen (

  number INTEGER,

  test TEXT,

  nickname TEXT,

  ter INTEGER,

  )

INSERT INTO Dzen (number,test,nickname,ter)

VALUES

  (1000,'Test', 'Munsera',42),

  (1001,'Test2','Yulkau',40),

  (1002,'Test4','Djeka',13),

  (1003,'Test4','Fritzfak',45),

  (1004,'Test5','Monax',11);

--COMMIT;

Проверяем что таблица создана и заполнена:

SELECT * FROM Dzen

Теперь выключаем сервер dbsql01.test.local, он был primary сервером. Проверяем:
  SELECT number FROM Dzen

База доступна, теперь внесем изменения в таблицу Dzen:

INSERT INTO Dzen (number,test,nickname,ter)

VALUES

  (1005,'Test5','Dismas',98)

 --COMMIT;

Проверяем: SELECT * FROM Dzen

Включаем сервер dbsql01.test.local, заходим в консоль SQL Server Management Studio сервера Dbsql01.test.local и проверяем:

SELECT * FROM Dzen

Данные сохранились. Выключаем сервер dbsql02.test.local и проверяем из консоли dbclt01.test.local

Все работает.

Проверяем работоспособность базы данных используя конфигурацию 1С: Тест Гилева. Запускаем тест и отключаем Primary сервер. Видим:

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

Заходим в консоль управления WSFC-кластера. Переходим в ветку Test_Group_1

Далее правой кнопкой мыши по ресурсу Test_group_1, переходим во вкладку Properties и изменяем параметр HealthCheckTimeout на 15000, это 15 секунд.

 Меньше число, к сожалению, поставить невозможно. Но т.к. таймаут опроса 1С сервером сервера SQL составляет 20 секунд, то при незагруженной работе, падение первичного SQL сервера, сервер 1С может пережить спокойно.

Приступим к тестированию производительности.

Запускаем тест Гилева:

Отключаем сервер с SSD дисками.

Как видно из тестов, можно увеличить производительность работы 1С практически в два раза за счет использования групп доступности AlwaysOn.

На этом предлагаю закончить.

Вопросы, замечания и предложения пишите в комментариях или на почту.

Удачного тестирования