 |
|
|
|
Live Migration. Что нужно для ее использования?
Live Migration Поговорим о возможностях и применении новой технологии, вошедшей в состав Microsoft Windows Server 2008 R2. В Microsoft Windows Server 2008 R2 появилось много новых возможностей. Среди них одной из самых интересных является технология, позволяющая перемещать виртуальные машины между узлами кластера с нулевым временем простоя. В предыдущей моей статье [1] было рассмотрено использование отказоустойчивых кластеров при виртуализации серверов, а здесь мы подробно рассмотрим одну из полезных возможностей такого решения – Live Migration, которая как раз и позволяет такое перемещение осуществлять. Live Migration: что за зверь и с чем его едят? Наверняка многим из читателей приходилось сталкиваться с проблемой, когда сервер необходимо на какое-то время выключить или перезагрузить: установка обновлений ОС, замена аппаратных компонентов. Приходилось оповещать всех пользователей, делать свое «черное дело», а потом снова оповещать всех, что-де все в порядке и можно продолжать работу. Иногда же приходилось оставаться на месте после окончания рабочего дня или же приходить в выходные дни. В некоторых случаях, когда требуется работа 24/7, это будет еще проблематичнее. Именно для таких случаев была придумана технология Live Migration, позволяющая переносить виртуальные машины с одного узла кластера на другой незаметно для пользователя. Как это работает? Сам процесс миграции может быть инициирован тремя способами:
После инициации процесса миграции файлы конфигурации виртуальной машины передаются на узел назначения и на нем создается пустая виртуальная машина (так называемый скелет), которой выделяется область памяти необходимого объема. Затем запускается процесс синхронизации содержимого памяти. В процессе синхронизации виртуальная машина продолжает работать. На рис. 1 показана область памяти, отведенная некоей виртуальной машине, расположенной на узле Node1. После запуска процесса синхронизации все содержимое памяти передается страницами по 4 Кб на целевой хост, где предварительно была выделена область памяти такого же объема, и содержимое записывается напрямую в память. Это первая итерация. В процессе передачи содержимое некоторых страниц было изменено (желтые ячейки). Поэтому запускается вторая итерация, в процессе которой копируются только измененные страницы. Так как их будет значительно меньше, чем суммарный объем памяти, процесс займет намного меньше времени, и после второй итерации содержимое памяти на обоих хостах будет идентично. На самом деле итераций может быть больше – до 10. Если достичь полной идентичности за 10 итераций не удается, процесс миграции прерывается. Это одно из слабых мест Live Migration: если виртуальная машина слишком активно работает с памятью, существует теоретическая возможность, что перенести ее с помощью Live Migration будет невозможно. В этом случае надо подождать спада активности или использовать другие методы перемещения, например Quick Migration. Сразу же после окончания процесса синхронизации – новой виртуальной машине передается управление всеми необходимыми дисками (как VHD, так и pass-through-дисками). Процесс такого «переключения» происходит практически мгновенно, TCP-соединения не успевают «отвалиться» по тайм-ауту, и пользователи не замечают, что что-то изменилось.
Рисунок 1. Процесс синхронизации содержимого памяти осуществляется итерационно Cluster Shared Volumes В Windows Server 2008 R2 появились так называемые Cluster Shared Volumes CSV – некий аналог кластерной файловой системы. Cluster Shared Volume (CSV), по сути, представляет собой кластерную файловую систему с единой точкой монтирования для общих дисковых ресурсов на всех узлах кластера. Кроме того, как известно, с каким-либо одним общим дисковым ресурсом кластера до недавнего времени одновременно мог работать только один из узлов. Поэтому, чтобы иметь возможность одновременной работы нескольких виртуальных машин на разных серверах, необходимо было для каждой виртуальной машины создавать отдельный LUN на системе хранения данных. Это могло породить некоторые проблемы при большом количестве виртуальных машин. Дело в том, что существуют технические ограничения на количество создаваемых LUN'ов в разных СХД. Использование Cluster Shared Volume позволяет решить эту проблему: доступ к одному и тому же CSV может осуществляться одновременно со всех узлов кластера, и поэтому количество виртуальных машин ограничивается лишь объемом дискового пространства. Как же выглядит Cluster Shared Volume в системе? На системном разделе (например, диск С:) всех узлов кластера создается папка ClusterStorage, и все дисковые устройства монтируются в ней, как подпапки с именем Volume1, Volume2 и т.д. Таким образом, доступ к файлам на одном и том же блочном устройстве на всех узлах кластера будет осуществляться по одному и тому же пути: C:\ClusterStorage\Volume1\. К сожалению, на данный момент Microsoft разрешает использовать CSV только для задач Hyper-V. Использование CSV в других целях является неподдерживаемым решением, о чем выводится соответствующее предупреждение при включении CSV. Основное требование для использования CSV – системный раздел на всех узлах кластера должен иметь одинаковую букву диска, например С:. Требования для использования Live Migration Существуют требования, которые необходимо соблюсти для использования Live Migration.
Помимо обязательных требований, рекомендуется:
Также обязательно надо учитывать, что при использовании Live Migration любые два узла кластера могут быть задействованы только в одном процессе миграции, и при этом перемещается только одна виртуальная машина. Нельзя одновременно перемещать несколько машин с одного хоста или на один хост. Это означает, что в кластере из N узлов может одновременно происходить N/2 процессов миграции. Основные сценарии применения Для чего же можно применять кластеры, и в частности Live Migration? Существует несколько общих сценариев. Сценарий 1. Техническое обслуживание серверов, установка обновлений Любой сисадмин периодически сталкивается с необходимостью замены или добавления какого-либо «железа» на сервере или с установкой обновлений ПО, требующих перезагрузки сервера. Так как при использовании виртуализации на одном физическом сервере запущено несколько виртуальных, выключение или перезагрузка физического сервера неизбежно затронет все виртуальные серверы, запущенные на нем. Поэтому, как правило, такие работы планируют на нерабочее время или на выходные дни, что не очень удобно для администраторов. Благодаря использованию Live Migration виртуальные машины могут быть перемещены на другой физический хост с нулевым временем простоя, что абсолютно незаметно для пользователя. Это означает, что любые работы, даже связанные с остановом сервера, можно проводить в разгар рабочего дня, просто переместив предварительно все виртуальные машины на другой сервер и не обзванивая пользователей с просьбой «выйти из программы». Сценарий 2. Динамическая ИТ-инфраструктура Благодаря использованию технологии Live Migration можно сделать ИТ-инфраструктуру полностью динамической. Очень сильно помогут в этом другие программные продукты – Microsoft System Center Virtual Machine Manager (VMM) и System Center Operations Manager (SCOM). Они позволяют следить за загруженностью всех физических хостов в реальном времени и в зависимости от загруженности перемещать виртуальные машины с более загруженных серверов на менее загруженные, распределяя таким образом нагрузку равномерно. Возможен и другой сценарий: при низкой загруженности серверов можно автоматически перемещать виртуальные машины, запуская большее число виртуальных машин на меньшем числе физических хостов. Неиспользуемые хосты при этом выключаются, что позволяет снижать энергопотребление и требования к кондиционированию в помещении серверной. При возрастании нагрузки в «часы пик» свободные хосты могут быть снова автоматически включены, и нагрузка может быть вновь равномерно распределена по хостам. От теории – к практике Теперь попытаемся «пощупать» Live Migration на практике: развернем кластер на настоящих серверах, создадим высокодоступную (High Available) виртуальную машину и попробуем ее мигрировать. Краткое описание тестовой среды Итак, что же мы имеем? Для работы с Live Migration развернута тестовая среда, включающая в себя:
Всего создано два iSCSI-устройства. Одно – объемом 0,5 Гб – будет использоваться в качестве кворума. Другое, 50 Гб – для хранения данных. Схема тестовой среды приведена на рис.2.
Рисунок 2. Тестовая среда для развертывания кластера Начальные настройки узлов кластера В качестве узлов кластера используются два компьютера – Node1 и Node2. У каждого из них имеется по два интерфейса Gigabit Ethernet – LAN1 и LAN2 (см. таблицу). Оба узла (Node1 и Node2) введены в домен TEST.LOCAL. Таблица. Настройки сетевых интерфейсов
Итак, первое, что нам необходимо сделать, – это подключить наши iSCSI LUN'ы. Для этого на первом узле заходим в Administrative Tools – iSCSI Initiator. Сервис iSCSI по умолчанию не запущен, поэтому система спросит, хотим ли мы, чтобы этот сервис запустился и стартовал автоматически. Соглашаемся. В окне настроек инициатора первое, что нам необходимо сделать, – это указать, где находятся наши iSCSI-диски. Заходим на закладку Discovery, выбираем Discover Portal и вводим адрес нашей системы хранения. В данном случае, как уже было написано, это сервер DC, то есть 10.0.0.1. Если все было указано правильно, в списке порталов появится наш сервер. Если были какие-то проблемы (например, порт закрыт файерволом или адрес неправильный), выдаст сообщение об ошибке. Теперь идем на закладку Targets и видим, что у нас появились два таргета со статусом Inactive. Нужно по каждому из таргетов кликнуть и нажать Connect. В появившемся окошке оставляем все по умолчанию (имя таргета должно оставаться, и верхняя галочка должна быть включена – тогда наш диск автоматически подключится при перезагрузке ОС, см. рис. 3).
Рисунок 3. Подключение iSCSI-дисков Затем переходим на закладку Volumes and Devices и выбираем Auto Configure. После этого можно закрывать окно свойств инициатора нажатием кнопки OK. Следующим шагом нам нужно зайти в консоль Server Manager в раздел Storage – Disk Management. Если все было сделано правильно, то там появятся два новых диска и оба будут в состоянии Offline. Переводим их в Online. Затем оба диска надо проинициализировать (Initialize) и создать разделы. Мы создадим на каждом диске по одному разделу объемом на весь диск и отформатируем в системе NTFS (другие не поддерживаются Microsoft Clustering Services). Присваиваем маленькому диску букву Q: и метку Quorum, а большому – S: и Storage соответственно. Естественно, это делается для удобства. После успешного завершения все будет выглядеть, как на рис. 4.
Рисунок 4. Окно оснастки управления дисками после создания разделов Затем надо установить роль Hyper-V и Failover Clustering. В оснастке Server Manager идем в раздел Roles, жмем Add Roles, в мастере выбираем роль Hyper-V и устанавливаем ее. Можно и даже желательно поставить галочку напротив сетевого адаптера, «смотрящего» в коммутатор, чтобы не создавать потом виртуальную сеть руками. Потребуется перезагрузка сервера, смиренно соглашаемся и ждем. После перезагрузки снова заходим на сервер. Через какое-то время мастер установки ролей продолжит работу. Надо подождать сообщения об успешной установке Hyper-V. Закрываем мастер, идем в Server Manager -> Features -> Add Features и выбираем всего одну компоненту: Failover Clustering. Все, больше нам здесь делать нечего. Заходим на второй узел и повторяем все точно так же, за исключением работы с дисками (инициализация-форматирование и т.д.): на втором узле iSCSI-диски должны остаться в состоянии Offline. За сим настройка узлов заканчивается. Создание отказоустойчивого кластера из двух узлов После того как мы подключили общие хранилища к узлам будущего кластера и установили необходимые компоненты системы, можно переходить к собственно настройке кластера. С любого из узлов (это не принципиально) или, как в нашем случае, с DC запускаем консоль Failover Cluster Manager (далее – FCM). Первое, что нам необходимо сделать, – это проверить, получится ли у нас вообще кластер из наших двух серверов. Для этого запускаем проверку: Validate a Configuration. Запустится мастер проверки конфигурации. Вначале выбираем наши оба узла. Далее нам будет предложено выбрать, запустить ли все тесты или только выбранные. Я и Microsoft настоятельно рекомендуем остановить выбор на Run All Tests, потому что только в этом случае решение будет поддерживаться Microsoft. Затем можно идти пить чай: проверка займет какое-то время, порядка 10 минут. Если все ОК, мы увидим что-то наподобие рис. 5.
Рисунок 5. Проверка конфигурации успешно завершена, можно собирать кластер Если были какие-либо проблемы, можно посмотреть отчет (View Report) в виде веб-страницы, где будет подробно объяснено, какие тесты провалились и почему. После исправления всех проблем надо запустить проверку заново. Итак, проверка успешно завершена, и можно наконец-таки собирать кластер. В FCM выбираем Create a Cluster. Появится мастер, похожий на предыдущий. Надо выбрать наши два узла, а затем ввести DNS-имя и IP-адрес для нашего кластера. В нашем случае – hvcluster с IP-адресом 10.0.0.10 (см. рис. 6).
Рисунок 6. Зададим сетевое имя и IP-адрес для нашего кластера Теперь кластер собран. Нужно убедиться, что в качестве кворума используется именно наш диск объемом 512 Мб. Заходим FCM – имя_кластера – Storage. В Disk Witness in Quorum должен стоять наш диск Q:, а второй диск (50 Гб) должен находиться в Available Storage. Использование Cluster Shared Volume Теперь было бы неплохо сделать так называемый Cluster Shared Volume. Включаем CSV: идем FCM – имя_кластера и выбираем Enable Cluster Shared Volumes. Выводится предупреждение о том, о чем я говорил выше – что CSV может использоваться только для виртуальных машинах и ни для чего более (см. рис. 7).
Рисунок 7. При включении Cluster Shared Volumes появляется предупреждение Ставим галочку, что мы все прочли и поняли, жмем ОК. В дереве слева появляется раздел Cluster Shared Volumes. Заходим туда, выбираем Add Storage – и выбираем наш диск, объемом 50 Гб. После этого он пропадает из Available Storage, но появляется в Cluster Shared Volumes и доступен на каждом узле как C:\ClusterStorage\Volume1. Создание высокодоступной виртуальной машины Для начала нужно создать саму виртуальную машину. Это можно сделать как непосредственно из консоли FCM, так и из оснастки Hyper-V Manager. В Hyper-V Manager нам заходить все равно придется, так что сделаем оттуда. Итак, на любом из узлов, допустим, на первом, создаем виртуальную машину. Обозвать ее можно как угодно – например TestVM. Память и все остальное – по вкусу. Но есть нюансы. Путь для сохранения файлов виртуальной машины не оставляем по умолчанию, а указываем наш кластерный диск (см. рис. 8).
Рисунок 8. Файлы виртуальной машины будем хранить на CSV Размер виртуального диска желательно во избежание конфуза указать меньше, чем размер нашего кластерного диска. Например – 20 Гб. Дальше все по вкусу. Сразу же, если мы собираемся использовать миграцию, а процессоры у серверов одного производителя, но разной модели (как в нашем случае), необходимо включить Processor Compatibility Mode. Заходим в свойства виртуальной машины (Settings) и в разделе Processor устанавливаем галочку Migrate to a physical computer with a different processor version (см. рис. 9).
Рисунок 9. Включаем Processor Compatibility Mode Теперь нам надо сделать нашу виртуальную машину высокодоступной. Термин «Высокодоступная (High Available)» виртуальная машина» означает, что виртуальная машина сконфигурирована особым образом для работы в кластере, и только в этом случае поддерживаются дополнительные возможности, связанные с кластерами, такие, как миграция между узлами. Возвращаемся в FCM – имя_кластера. В разделе Services and applications выбираем Configure Servise or Application. В мастере указываем, что это будет виртуальная машина (Virtual Machine внизу списка), и выбираем нашу созданную виртуальную машину (TestVM). Виртуальные машины можно создавать прямо из FCM, и тогда они сразу же автоматически делаются высокодоступными, но тем не менее придется зайти в Hyper-V Manager для настроек процессора (см. выше). Использование Live Migration Теперь на нашу готовую и высокодоступную виртуальную машину можно (и нужно!) установить ОС. Какую ОС ставить – это ваш выбор. После установки ОС можно проверить Live Migration. Для этого можно, например, запустить непрерывный пинг нашей виртуальной машины в отдельном окне или качать на нее/с нее какой-нибудь большой файл (фильм в HD весом в 25 Гб, например). Пока все это безобразие происходит, попробуем тихонечко перенести нашу многострадальную виртуальную машину на другой узел. Кликаем на ней правой кнопкой и выбираем Live Migrate, а в выпадающем меню – тот узел, куда она будет переезжать. Процесс миграции занимает пару секунд – и мы видим, что Current Owner изменился. Если открыть Hyper-V Manager, то можно убедиться, что наша виртуальная машина находится уже на другом узле. При этом во время миграции ни пинг, ни закачка файла, как мы видим, не прерываются. Ура! *** Итак, в этой статье мы ознакомились с новой «изюминкой» Microsoft Windows Server 2008 R2: Live Migration. Мы узнали, что нужно для ее использования, как происходит сам процесс миграции, и осуществили все описанное на практике. Надеюсь, что вы нашли эту статью полезной.
|
АЛЕКСАНДР КОСИВЧЕНКО, технический специалист ЗАО «Компьювэй». Занимается внедрением серверных решений на базе ПО Microsoft
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
