Главная Virtualization, Новое Windows Server 2008 R2 Hyper-V Live Migration: теперь миграция стала живой!
  • Windows Server 2008 R2 Hyper-V Live Migration: теперь миграция стала живой!

    migration Гипервизор Windows Server 2008 R2 основан на архитектуре Windows Server 2008 Hyper-V с добавлением множества новых возможностей, значительно повышающих гибкость продукта. Применение виртуализации на предприятиях привело к повышению гибкости в развертывании и управлении жизненным циклом приложений. Виртуализация использовалась IT-профессионалами для консолидации рабочих нагрузок и повышения эффективности использования вычислительных мощностей. Кроме того, виртуализация может использоваться совместно с технологиями кластеризации, что позволит создать надежную IT-инфраструктуру с высокой доступностью и быстрым восстановлением в случае сбоя. К тому же, заказчики заинтересованы в еще большей гибкости системы. Windows Server 2008 R2 предоставляет дополнительную гибкость за счет технологии Live Migration.

    Технология Live Migration поддерживается как в Windows Server 2008 R2, так и в Microsoft Hyper-V Server 2008 R2. При помощи Hyper-V Live Migration можно перемещать виртуальные машины с одного физического хоста на другой без остановки самой виртуальной машины. Технология Live Migration предоставляет возможности для динамической балансировки нагрузки, высокой доступности виртуальной среды во время технического обслуживания физического хоста и понижения общего энергопотребления системы.

    В Windows Server 2008 R2 Hyper-V были добавлены очень ценные новые возможности, наряду с теми, что уже были в Windows Server 2008. К примеру, с использованием технологии Live Migration, можно перемещать виртуальные машины между физическими хостами «на лету». Виртуальные диски могут быть добавлены и удалены без остановки виртуальной машины. Кроме того, гипервизор Windows Server 2008 R2 более эффективно использует аппаратные ресурсы хоста. Этот документ представляет собой обзор новых возможностей Windows Server 2008 R2 Hyper-V и подробную информацию о технологии Live Migration.

    Динамическое хранение виртуальных машин

    Гипервизор Windows Server 2008 R2 Hyper-V поддерживает горячее подключение и отключение хранилищ. Благодаря возможности добавления или удаления виртуальных дисков VHD и pass-through дисков на работающей виртуальной машине можно легко переконфигурировать виртуальную машину в соответствии с изменившимися требованиями.

    Примечание: для использования горячего добавления и удаления виртуальных дисков необходимо установить Hyper-V Integration Services в гостевой ОС.

    Улучшенная поддержка процессоров

    Windows Server 2008 R2 Hyper-V поддерживает до 32 логических процессорных ядер. Улучшенная поддержка процессоров позволяет консолидировать еще большую нагрузку на один физический сервер.

    Windows Server 2008 R2 Hyper-V так же поддерживает SLAT (Second-Level Address Translation) и CPU Core Parking. SLAT использует особые возможности, имеющиеся в процессорах Intel, поддерживающих Extended Page Tables и процессорах AMD с поддержкой Rapid Virtualization Indexing для использования некоторых функций управления памятью виртуальных машин, которые снижают накладные расходы на трансляцию адресов внутри виртуальной машины в адреса на физическом хосте. Это значительно снижает нагрузку на процессоры и расход оперативной памяти каждой виртуальной машиной, позволяя физическому хосту выполнять больше работы с меньшей утилизацией системных ресурсов. CPU Core Parking позволяет снижать энергопотребление благодаря назначению виртуальной машине только нескольких процессорных ядер, переключая остальные ядра в спящий режим.

    Улучшенная поддержка сети

    В Windows Server 2008 R2 появились некоторые новые улучшения, касающиеся работы с сетью, повышающие быстродействие сетевых компонент в виртуальной среде. Поддержка Jumbo Frames теперь доступна так же и в виртуальной среде. Благодаря этому виртуальные машины теперь поддерживают Jumbo Frames размером до 9014 байт при условии, что физические сетевые компоненты (сетевые адаптеры, коммутаторы и т.д.) поддерживают их. Поддержка Jumbo Frames позволяет снизить накладные расходы сетевого стека на байт переданной информации и повышает пропускную способность. Так же это позволяет снизить утилизацию процессора благодаря меньшему числу обращений от сетевого стека к драйверу сетевого адаптера в еденицу времени.

    Функция TCP Chimney, позволяющая передать обработку TCP/IP-пакетов процессору сетевого адаптера теперь так же поддерживается в виртуальной среде. Это позволяет повысить производительность виртуальных машин за счет передачи части нагрузки процессорам сетевых адаптеров, что особенно заметно на при большой сетевой нагрузке, к примеру – файловые серверы или хранилища данных с подключением по iSCSI.

    Благодаря использованию Virtual Machine Queue (VMQ) сетевые адаптеры физического хоста могут использовать DMA, помещая обработанные сетевые пакеты напрямую в память виртуальных машин, повышая производительность сетевого стека.

    Cluster Shared Volume (CSV)

    В Windows Server 2008 R2 совместное использование хранилищ данных значительно упрощено засчет использования CSV. Использование CSV позволяет нескольким серверам осуществлять доступ к хранилищу данных SAN в едином пространстве имен для всех томов на всех хостах. Различные хосты могут иметь доступ к одному и тому же логическому устройству (LUN) в хранилище данных SAN. CSV позволяет использовать Live Migration и доступна как элемент служб отказоустойчивой кластеризации Windows Server 2008 R2.

    Live Migration

    Одной из наиболее важных и ожидаемых возможностей гипервизора Windows Server 2008 R2 Hyper-V является технология Live Migration. Оставшаяся часть настоящего документа детально описывает технологию Live Migration, в том числе – как происходит перемещение работающих виртуальных машин, описывает несколько сценариев, при которых технология Live Migration оказывается достаточно полезной и требования, необходимые для внедрения Live Migration.

    Обзор техологии Live Migration

    Как говорилось ранее, технология Live Migration поддерживается в Windows Server 2008 R2 Hyper-V и в Microsoft Hyrer-V Server 2008 R2. Благодаря Live Migration можно перемещать работающие виртуальные машины с одного физического хоста на другой без какого-либо простоя.

    Поскольку технология Live Migration позволяет перемещать работающие виртуальные машины без простоя, ее применение может способствовать повышению гибкости и отказоустойчивости системы:

    1. Повышение быстродействия: При использовании в датацентре множества хостов на базе Hyper-V появляется возможность перемещения работающих виртуальных машин не заметно доя пользователей на наиболее подходящий физический хост для повышения быстродействия, масштабируемости и оптимальной консолидации.

    2. Снижение затрат и повышение продуктивности: В датацентра со множеством хостов на базе Hyper-V можно производить работы по техническому обслуживанию серверов в рабочее время без остановки сервисов. Live Migration позволяет оставлять виртуальные машины работающими даже во время технического обслуживания серверов, тем самым повышая продуктивность как пользователей так и технического персонала. Также, за счет повышения консолидации и отключения временно неиспользуемых серверов.

    Live Migration в сравнении с Quick Migration

    Возможность Quick Migration присутствовала в Hyper-V изначально, еще в Windows Server 2008. И Quick Migration, и Live Migration предназначены для переноса работающих виртуальных машин между физическими хостами с одной небольшой разницей: Quick Migration переносит виртуальные машины, производя операцию сохранения состояния (Save State), что приводит к кратковременному простою виртуальной машины. При Live Migration же, используется другой механизм переноса виртуальных машин. Этот процесс будет детально описан в соответствующей секции настоящего документа. Вкратце перенос происходит так:

    1. Все страницы памяти виртуальной машины транслируются с хоста-источника на хост назначения.

    2. Во время процесса переноса виртуальной машины все изменения страниц памяти автоматически отслеживаются и реплицируются на хост назначения.

    3. Указатели на виртуальные диски передаются на хост назначения.

    4. Виртуальная машина запускается на хосте назначения.

    Процесс Live Migration значительно снижает время простоя виртуальных машин во время миграции. Благодаря этому использование Live Migration предпочтительно при переносе виртуальных машин, к которым требуется непрерывный доступ пользователей. Благодаря тому, что процесс Live Migration завершается быстрее, чем наступает тайм-аут TCP-соединения, процесс миграции происходит абсолютно прозрачно для конечного пользователя.

    Примечание: Live Migration и Quick Migration поддерживаются только в версии Windows Server 2008 R2 и Hyper-V Server 2008 R2. В версиях Windows Server 2008 и Hyper-V Server 2008 поддерживается только Quick Migration, Live Migration не поддерживается.

    Архитектура Live Migration

    Технология Hyper-V Live Migration разработана для перемещения запущенных виртуальных машин незаметно для конечных пользователей. За счет пре-копирования страниц памяти виртуальной машины на хост назначения достигается минимизация времени, затраченного на перенос, а гостевая операционная система вообще «не замечает», что ее куда-то переносили, соответственно использование Live Migration не требует какой-либо дополнительной настройки внутри гостевой ОС.

    Требования

    Требования для Live Migration – такие же, как и для Quick Migration: если в организации уже используется Quick Migration, то переход на использование Live Migration будет достаточно простым. Физические хосты, которые будут участвовать в процессе миграции должны быть сконфигурированы в отказоустойчивый кластер на базе Microsoft Failover Clustering и использовать общее хранилище данных. Кроме того, все узлы кластера должны иметь одинаковый тип процессора (то есть процессоры одного и того же производителя). Полный список требований для Live Migration приведен ниже:

    1. Поддерживаемые версии ОС:

    a. Windows Server 2008 R2 64bit Enterprise Edition

    b. Windows Server 2008 R2 64bit Datacenter Edition

    c. Hyper-V Server 2008 R2

    2. Все физические хосты, на которых будет применяться Live Migration, должны быть узлами кластера Microsoft Failover Clustering.

    3. Кластеризация Microsoft поддерживает до 16 узлов в одном кластере.

    4. Кластер следует конфигурировать с использованием отдельной физической сети для трафика Live Migration.

    5. Все узлы кластера должны иметь процессоры одного производителя.

    6. Все хосты должны принадлежать к одной IP-подсети.

    7. Все хосты должны иметь доступ к общему хранилищу данных.

    Рекомендации:

    8. Для хранения файлов виртуальных машин рекомендуется использовать Cluster Shared Volume.

    9. Между любыми двумя узлами кластера в один момент времени может происходить один процесс Live Migration. Это означает, что в кластере может одновременно происходить N/2 процессов миграции, где N – число узлов кластера. К примеру, в кластере из 16 узлов может одновременно проходить до 8 процессов миграции, при этом каждый узел может быть задействован только в одном процессе.

    10. Для передачи большого количества страниц памяти виртуальных машин рекомендуется объединить узлы кластера дополнительной изолированной сетью с высокой пропускной способностью (1Gbps и выше).

    11. Конфигурация кластера должна удовлетворять Microsoft Support Policy for Windows Server 2008 Failover Clusters: http://support.microsoft.com/default.aspx?scid=kb;EN-US;943984

    Принципы работы Live Migration

    Как уже было сказано, технология Live Migration была разработана для перемещения виртуальных машин с одного физического хоста на другой за минимальное время. Процесс Live Migration инициируется администратором с помощью одного из трех методов (см. ниже). Фактическая скорость процесса миграции зависит как от характеристик используемого оборудования, так и от пропускной способности сети.

    Итак, существует три способа запуска процесса Live Migration:

    1. Администратор может запустить процесс миграции с использованием оснастки MMC Failover Cluster Management.

    2. Через консоль System Center Virtual Machine Manager (если используется).

    3. С помощью скрипта с использованием WMI или PowerShell.

    Любая гостевая ОС будет продолжать работу в процессе миграции. После запуска процесса Live Migration, происходит следующее:

    1. Подготовка к миграции

    На первой стадии процесса Live Migration (см. рис. 1), хост-источник устанавливает TCP-соединение с хостом назначения. Это соединение используется для передачи конфигурации виртуальной машины на хост назначения. На хосте назначения создается «виртуальная машина – скелет» и ей выделяется необходимый объем памяти.

    clip_image002

    Рис. 1. Подготовка к процессу миграции

    2. Передача страниц памяти на хост назначения

    На второй стадии процесса миграции (см. рис. 2), содержимое области памяти, выделенной виртуальной машине копируется по сети на хост назначения страницами по 4 килобайта. Объем памяти, выделенной конкретной виртуальной машины далее будем называть «рабочим объемом памяти» виртуальной машины.

    К примеру, имеется виртуальная машина пож названием NYC-SVR2, сконфигурированная с объемом памяти 1024MB мигрирует на другой хост под управлением Hyper-V. Эти 1024MB и составляют ее рабочий объем памяти. Используемые страницы памяти внутри рабочего объема NYC-SVR2 копируются на сервер назначения.

    Параллельно с копированием рабочего объема, гипервизор хоста-источника следит за состоянием памяти NYC-SVR2. Как только какие-либо страницы памяти подвергаются изменению, они тотчас же отмечаются как «модифицированные». Таким образом формируется список страниц, подвергшихся модификации с начала процесса копирования.

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

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

    clip_image004

    Рис. 2. Передача содержимого памяти

    3. Передача измененных страниц памяти

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

    В течение этой стадии, процесс миграции сильно зависит от пропускной способности сети, поэтому рекомендуется использовать высокоскоростное сетевое соединение – как минимум Gigabit Ethernet. Чем быстрее будут передаваться измененные страницы памяти – тем быстрее завершится процесс миграции.

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

    После того, как все измененные страницы были полностью скопированы, на хосте назначения появляется точная копия рабочего объема памяти NYC-SVR2.

    Примечание: Процесс Live Migration может быть прерван в любое время до момента начала этой стадии.

    clip_image006

    Рис. 3. Передача измененных страниц памяти

    4. Передача управления виртуальными дисками

    На четвертой стадии миграции (см. рис. 4), управление хранилищами данных, связанными с NYC-SVR2, как-то: VHD-файлами и pass-through дисками, передается хосту назначения.

    clip_image008

    Рис. 4. Передача управления виртуальными дисками

    5. Запуск виртуальной машины на сервере назначения

    На пятой стадии (см. рис. 5) на хосте назначения создается абсолютно точная копия рабочего объема памяти виртуальной машины и доступ ко всем используемым ею хранилищам данных. Теперь виртуальная машина запускается на хосте назначения.

    clip_image010

    Рис. 5. Виртуальная машина запускается на сервере назначения

    6. Обновление ARP-таблицы

    Виртуальная машина успешно запущена на хосте назначения. После этого сетевому коммутатору посылается ARP-пакет, и коммутатор «узнает» новый MAC-адрес мигрировавшей виртуальной машины, и сетевой трафик перенаправляется на соответствующий порт.

    Процесс миграции завершится за меньшее время, чем произойдет тайм-аут для TCP-соединения виртуальной машины. Интервалы тайм-аутов соединения зависят от топологии сети и множества других факторов. Следующие факторы могут повлиять на скорость миграции:

    · Количество измененных страниц памяти виртуальной машины: чем больше страниц подвергается модификации, тем больше времени займет процесс миграции.

    · Пропускная способность сети между двумя хостами.

    · Конфигурация оборудования хостов.

    · Пропускная способность соединения между хостами и общим хранилищем данных (SAN).

    Сценарии использования Live Migration

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

    Техническое обслуживание серверов

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

    Поскольку виртуальные машины могут быть перемещены на другой физический хост с нулевым временем простоя, можно произвести миграцию перед проведением работ по обслуживанию сервера. После окончания работ и запуска сервера, можно перенести виртуальные машины обратно опять-таки незаметно для пользователей. Благодаря этому, работы по обслуживанию серверов можно производить в рабочее время. Кроме того, поскольку миграция может быть запущена при помощи скриптов (через WMI или PowerShell), многие операции по обслуживанию серверов могут быть автоматизированы. ПО, которое может создавать скрипты или использовать функции WMI, например Microsoft System Center Configuration Manager, может быть сконфигурировано для использования Live Migration.

    clip_image012clip_image014clip_image016

    Рис. 6. Live Migration и обслуживание хоста в рабочее время

    Динамический датацентр

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

    Например, если используется некое Web-приложение, и число запросов к нему значительно выросло – Microsoft System Center Virtual Machine Manager (SCVMM) может автоматически предоставить один или несколько дополнительных Web-серверов. При предоставлении этих веб-серверов, Virtual Machine Manager принимает во внимание нагрузку на аппаратные сервера. При возрастании нагрузки Virtual Machine Manager может переключится на дополнительные физические хосты и запустить больше виртуальных машин – чтобы справиться с возросшей нагрузкой.

    Поскольку нагрузка меняется, виртуальные машины могут перемещаться между физическими хостами для поддержания высокой утилизации аппаратных ресурсов. Неиспользуемые сервера могут быть выключены, что позволяет сэкономить электроэнергию и понизить требования к охлаждению, понижая, таким образом, затраты на работу инфраструктуры. Несоответствие характеристик физического хоста и требований для запуска виртуальной машины становится не таким фатальным, поскольку виртуальные машины могут быть перемещены на более мощный хост без каких-либо простоев. С помощью Virtual Machine Manager можно создавать отчеты о загрузке серверов, что поможет в выборе идеального сервера для миграции виртуальной машины.

    clip_image018

    Рис. 7. Виртуальные машины перемещаются на менее нагруженный хост.

    Green IT

    Порядка 33% энергии, потребляемой датацентрами, расходуется на охлаждение и поддержку инфраструктуры. Гибкая балансировка нагрузки, возможная благодаря использованию технологии Live Migration, позволяет снизить общее энергопотребление датацентра. Если нагрузка на оборудование датацентра постоянно меняется, можно использовать автоматизацию с помощью скриптов и Live Migration для повышения консолидации виртуальных машин при относительно невысокой загруженности. Если удается запустить большее число виртуальных машин на меньшем числе физических хостов – неиспользуемые сервера могут быть выключены, что позволит снизить энергопотребление и требования к охлаждению в помещении датацентра. При пиковых нагрузках, отключенные сервера могут быть вновь автоматически запущены и виртуальные машины будут перераспределены по свободным хостам с использованием технологий Live Migration.

    Функция Live Migration является частью Windows Server 2008 R2 Hyper-V и не требует покупки каких-либо дополнительных лицензий и/или использования дополнительного ПО. В принципе любая аппаратная конфигурация, которая поддерживает Quick Migration – может так же поддерживать и Live Migration, без инсталляции дополнительного оборудования, ПО и без покупки дополнительных лицензий.

    clip_image020

    Рис. 8. Повышение консолидации.

    Развертывание Live Migration

    Поскольку в Windows Server 2008 процесс развертывания отказоустойчивого кластера был значительно упрощен – развертывание Live Migration достаточно просто. В начале, в процессе планирования, необходимо выяснить, сколько понадобится узлов в кластере. Затем необходимо убедиться, что используемые сервера и система хранения данных соответствует требованиям для Microsoft Failover Clustering (см. Microsoft Failover Cluster Configuration Program).

    Процесс развертывания включает в себя следующие шаги:

    1. Создать кластер Windows Server 2008 Failover Clustering

    2. Подключить все узлы к сети и СХД

    3. Включить Hyper-V и Failover Clustering на всех узлах

    4. Включить Cluster Shared Volumes

    5. Сделать виртуальные машины отказоустойчивыми (Make Highly Available)

    6. Протестировать процесс Live Migration

    Детализированные пошаговые инструкции можно найти на сайте: http://go.microsoft.com/fwlink/?LinkId=139667

    Управление Live Migration

    При использовании Live Migration может быть целесообразно использовать Microsoft System Center Virtual Machine Manager 2008 R2. Функции управления виртуальными машинами и построения отчетов Virtual Machine Manager могут использоваться совместно с технологией Live Migration, что позволит значительно упростить управление виртуальной средой. Использование Virtual Machine Manager вместе с Live Migration позволит организации реагировать на изменение нагрузки и требований. Также, Virtual Machine Manager можно использовать для управления отдельными хостами Hyper-V, в том числе и находящимися на удаленных площадках.

    При управлении с помощью Virtual Machine Manager хостом, сконфигурированным для работы в режиме высокой доступности, Virtual Machine Manager может запускать процесс Quick Migration или Live Migration прямо из консоли Virtual Machine Manager, что является очень удобным для администраторов.

    Поскольку прямо из консоли Virtual Machine Manager можно генерировать скрипты PowerShell на любое действие, выбранное администратором, в дальнейшем рутинные задачи администрирования могут быть автоматизированы. Разумеется, это касается и технологии Live Migration. Используя Virtual Machine Manager для запуска процесса переноса виртуальной машины на другой физический хост с нулевым временем простоя, можно также получить скрипт PowerShell, с помощью которого можно в дальнейшем автоматически запустить тот же самый процесс, или с помощью незначительных изменений скрипта указать другую виртуальную машину, и/или другие хосты-источник и назначения.

    С помощью Virtual Machine Manager можно получать исчерпывающие отчеты об утилизации аппаратных ресурсов серверов и размещении виртуальных машин на физических хостах. Эти отчеты могут помочь в принятии решения о создании новых виртуальных машин и переносе существующих на другие хосты. В частности, в средах с высокой плотностью, таких, как многие датацентры или в разрозненной среде, такой, как множество удаленных площадок, достоверная информация по виртуализации и производительности систем может оказаться жизненно-важной для выполнения требований к надежности и быстродействию всей системы. С помощью Virtual Machine Manager можно получить всю необходимую информацию для эффективного управления множеством хостов и виртуальных машин. Поскольку благодаря использованию Live Migration, перенос виртуальных машин между хостами становится предельно простым и быстрым, обладание достоверной информацией о хостах становится особенно важным.

    Резюме

    Технология Live Migration, поддерживаемая гипервизором Windows Server 2008 R2 Hyper-V значительно повышает гибкость виртуальной инфраструктуры. Возможность перемещения виртуальных машин между физическими хостами без какого-либо простоя самих виртуальных машин значительно упрощает обслуживание физических хостов и открывает новые возможности для построения динамической инфраструктуры, наиболее приспособленной для изменяющихся требований. Технология Live Migration позволяет производить работы по обслуживанию физических хостов без запланированного простоя виртуальных машин. Когда изменяются требования к работе виртуальной машины, ее можно перенести на более мощный или менее загруженный сервер без останова, или, если требования снизились, можно перенести ее на более загруженный сервер для повышения консолидации и понижения энергопотребления системы. Технология Live Migration позволяет использовать VM с меньшими трудозатратами и большей гибкостью, чем ранее. Эти преимущества означают снижение затрат времени и денег практически для любой инфраструктуры, использующей виртуализацию на базе Microsoft Hyper-V.

    Перевод: Косивченко Александр

    • Рубрика: Virtualization,Новое
    • Автор: Александр Косивченко
    • Дата: Monday 20 Jul 2009

Комментарии

  1. Есть вопросы:

    Я так понимаю Live Migration всегда подразумевает хранение дисков виртуальной машины на внешнем хранилище. А сам Live Migration на базе Failover Cluster передает управление виртуальной машиной и состояние памяти.

    Если это так то не очень понято как работает сценарий Динамический датацентр. Мне это видится так, один сервер захлебнулся перекинул управление виртуальной машиной на другой?

    Еще один момент. Указано что осуществить Live Migration можно несколькими способами и каждый подразумевает участие админа. Что будет если упадет тот нод Hyper-V кластера, который был активным? Продолжит ли работу виртуальный сервер и почувствуют ли это пользователи?

    И последнее, только что установил в Hyper-V R2 операционную систему Windows 2008R2 и к сожалению нельзя на горячую добавить VHD диск(( Установить Дополнения для ОС не дает, говорит и так последняя версия установлена.

  2. >Если это так то не очень понято как работает сценарий Динамический
    >датацентр. Мне это видится так, один сервер захлебнулся перекинул
    >управление виртуальной машиной на другой?
    Не совсем. Ставится SCVMM – это аналог VirtualCentre от VMWare, тока от MS. Этот VMM умеет мониторить загрузку серверов, и в случае достижения определенных пороговых значений может, к примеру, запускать скрипт, осуществляющий перенос виртуалки на другой хост.

    > Что будет если упадет тот нод Hyper-V кластера, который был активным?
    > Продолжит ли работу виртуальный сервер и почувствуют ли это пользователи?
    Если я правильно понял – виртуалка стартует на другом хосте, но все же это будет холодный запуск – т.е. как будто виртуалку выключили и запустили снова. Потому что я не представляю, как можно передавать абсолютно все изменения в RAM виртуалки на лету в реальном масштабе времени даже по гигабитной сети, чтобы неожиданный сбой не был заметен. Это надо что-то типа InfiniBand’а использовать, наверное.

    >И последнее, только что установил в Hyper-V R2 операционную систему Windows 2008R2 и к сожалению нельзя на горячую добавить VHD диск((

    Надо будет проверить и почитать.

    Вообще, если честно, в живую с Live Migration я дела не имел, текст статьи – всего-лишь перевод Whitepaper от MSFT. В очень скором времени я проверю все это на практике 🙂

  3. Очень смешно наблюдать как маркетинг Microsoft вертится аки флюгер на ветру. Всего год назад утверждалось, что Live Migration реально нужна лишь нескольким процентам заказчиков. Что характерно, на тот момент LM была у VMware, Citrix, Oracle, Virtual Iron. Иными словами, у всех, КРОМЕ Microsoft.

    >Этот VMM умеет мониторить загрузку серверов, и в случае достижения определенных пороговых значений может, к примеру, запускать скрипт, осуществляющий перенос виртуалки на другой хост.

    SCVMM уже научился динамической балансировке, аналогичной VMware DRS? Или все-таки Intelligent Placement – разброс ВМ по хостам при _старте_ ВМ.

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

    VMware Fault Tolerance 🙂

  4. Антон, вы не могли бы приблизительно сказать какую сумму нужно вложить при создании кластера “VMware Fault Tolerance” состоящего из трех нодов?

  5. 2Anton:
    > Что характерно, на тот момент LM была у VMware, Citrix, Oracle, Virtual Iron. Иными словами, у всех, КРОМЕ Microsoft.

    Да, есть такое дело. MS просто слишком поздно вошел на рынок серверной виртуализации. До этого у них был VirtualServer, но он воспринимался скорее как тестовая платформа, чем именно как серьезная платформа для виртуализации. Но учитывая то, как они практически за год догоняют VMWare – думаю, что потенциал у них очень даже неплохой.
    И еще, что характерно, лицензирование у MS намного удобнее, чем у VMWare. MS не требует лицензий на процессорные ядра (только на сокеты, и то только в версии Datacenter), не требует лицензий на дополнительные фичи типа LM или бэкапа, ну и так далее. Есть вообще Hyper-V Server R2, который, будучи бесплатным(!), поддерживает кластеризацию с Live Migration. ESXi в бесплатном варианте ничего, кроме собственно запуска виртуальных машин не умеет.
    Минусом и при этом плюсом Hyper-V так же является поддержка гостевых операционных систем. Минус в том, что из не-майкрософтовских ОС официально поддерживается только SUSE Linux. Плюс в том, что если используются ОС от MS – то использование Hyper-V (за исключением Hyper-V Server) дает право на бесплатное использование гостевых ОС (Standard – 1шт, Ent – 4шт, DC – неограниченно на один хост).

  6. Илья, Fault Tolerance включена в издание vSphere Advanced, и не требует отдельных “бешеных бабок” для приобретения. Advanced – не самое дорогое издание vSphere.

  7. Мне просто кажется, что пока это разного уровня продукты, и по цене и по кол-ву возможностей. А маркетинг он и в Африке маркетинг, у МС он ничем от других компаний не отличается.

  8. >MS просто слишком поздно вошел на рынок серверной виртуализации.

    Александр, к MS нет технических претензий. Hyper-V интересный продукт, который _входит_ на рынок, и реальная его аудитория на сейчас – SMB. Претензии к маркетингу MS, который неадекватно его позиционирует и не стесняется откровенно лгать, менять позицию на диаметрально противополжную и нести полную чепуху.

    Пока что Hyper-V не догоняет, он набирается базовой функциональности. Теперь остается ее отшлифовать и доказать, что Hyper-V достаточно стабилен и масштабируем. Вот тогда можно будет говорить, что Hyper-V в 2009 году догнал VMware ESX 2005-2006 годов.

    Серверные продукты VMware лицензируются по сокетам.

    Александр, давайте мух отдельно, а котлеты отдельно. Мы говорим о “бесплатности”, стоимости и тому подобном в минимальном наполнении, для SMB? Так я и не спорю, что Hyper-V становится все интереснее для SMB. И в частности в силу бОльшей наполненности функционалом за малые деньги. НО! Hyper-V R2 когда вышел? А сколько уже жужжат о его функционале и сравнивают еще не вышедший продукт MS с продуктом VMware _предыдущего_ поколения?

    Если говорить не о SMB с одним-двумя серверами, а Enterprise хотя бы с 10-15 хостами и 100+ ВМ, то картина меняется. Вплоть до того, что “бесплатность” Hyper-V может оказаться дороже “сверхдорогого” ESX. И в конечном итоге, рано или поздно мы упермся в то, что у MS просто нет того функционала и обвязки, какой есть у VMware.

  9. Илья, полный консенсус.

  10. “но все же это будет холодный запуск — т.е. как будто виртуалку выключили и запустили снова”

    не совсем так – процесс похож на запуск ВМ из состояния Saved State

  11. В первую очередь, Александр, спасибо за консолидацию материала.
    Во-вторую, добавлю “свои пять копеек”.
    На рынке SMB несколько миллионов компаний с одним – двумя серверами, а вот Enterprise сегмент чуть больше списка Fortune 1000.. Поэтому и сейчас Microsoft утверждает что live migration нужна лишь нескольким процентам заказчиков. Сценарий Технического обслуживания, к примеру, есть в каждой компании – и практически все из них как-то да жили без Live Migration (и других технологий переноса машин без простоя). Перенос систем через ВМ – сокращает количество времени на обслуживание систем (с нескольких часов до нескольких минут). Кроме того, не нужно забывать что появление в сети нового компонента (для обеспечения все той же миграции) приводит к дополнительным затратам на свое же обслуживание (те VMWAre – все равно придется обновлять, в дополнении к обслуживанию железных систем – что приводит к потредности миграции сисием с этого узла и тп).. Маркетинг этого не говорит?? ;)) также как и то что пободоносный “Fault Tolerance” – имеет несколько десятков ограничений на развертывание и применение… (сразу замечу что для Hyper-V подобную функциональность обещает добавить компания Marathon после выхода WS08R2). Маркетинг также старается показать что добавив решения виртуализации в ваш “зоопарк” систем – все ваши старые проблемы испугаются и уйдут. Только купите V-Motion, DRS, Memory Overcommitments, etc… =) Интересно в случае отказа работы одной из служб, скажем контроллера домена или Иксченджа – как они решат эту проблему? Подход к виртуализации у Microsoft и VMWare (самого дорого вендора гипервизоров) иной. Одни говорят – оптимизируйте инфраструктуру (используйте современные возможности, разворачивайте по умному, избавляйтесь от камнейпроблем – тянущих вас вниз счейчас и в будущем, в то время как другие отмечают что чихать хотели на то, что за системы и как работают выше их слоя, как их используют или нет сотрудники компаний – главное это “купить свободу размещения ВМ” (цитата из доклада VWMAre) и жизнь после этого наладится).

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

    И контроллерам домена, и базам данных и почтовым системам (как и многим другим компонентам) – в случае правильного развертывания – все равно вышел узел из строя или нет – клиенты получат нужный сервис все равно. Безусловно, есть и исключения в виде унаследованных приложений, особого режима функционирования и тп.. Но, давайте честно признаемся – не виртуализацией единой жили, живем и жить будем… =)

  12. Спасибо за внятное описание Live Migration.

    Владимир (#11), как инженер могу сказать, что на маркетинговые обещания всегда стоит смотреть с большим скепсисом.

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

    To Владислав (#10):
    >>«но все же это будет холодный запуск — т.е. как будто виртуалку выключили и запустили снова»
    >не совсем так — процесс похож на запуск ВМ из состояния Saved State
    Разве? А оперативная память, которой вдруг не стало? Как-то совсем не похоже на Saved State. Просто взяли и топнули РЕСЕТ физической машине – прямая аналогия.