Главная Virtualization, Новое Live Migration: как это работает
  • Live Migration: как это работает

    image Поговорим об одной из новых технологий, вошедших в состав Microsoft Windows Server 2008 R2, известной как Live Migration.

    (оригинал статьи опубликован в журнале “Системный Администратор”, октябрь 2009г.)

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

    Live Migration: что за зверь, и с чем его едят?

    Наверняка многим из читателей приходилось сталкиваться с проблемой, когда сервер необходимо на какое-то время выключить или перезагрузить: установка обновлений ОС, замена аппаратных компонент. Приходилось оповещать всех пользователей, делать свое «черное дело», а потом снова оповещать всех, что-де все в порядке и можно продолжать работу. Иногда же приходилось оставаться на месте после окончания рабочего дня, или же приходить в выходные дни. В некоторых случаях, когда требуется работа 24/7 – это будет еще проблематичнее. Именно для таких случаев была придумана технология Live Migration, позволяющая переносить виртуальные машины с одного узла кластера на другой незаметно для пользователя.

    Как это работает?

    Сам процесс миграции может быть инициирован тремя способами:

    1. Вручную через оснастку Failover Clustering;
    2. С помощью командлета PowerShell;
    3. С помощью дополнительного ПО, например System Center Virtual Machine Manager.

    После инициации процесса миграции – файлы конфигурации виртуальной машины передаются на узел назначения, и на нем создается пустая виртуальная машина (так называемый «скелет»), которой выделяется область памяти необходимого объема.

    Затем – запускается процесс синхронизации содержимого памяти. В процессе синхронизации виртуальная машина продолжает работать.

    clip_image002

    Процесс синхронизации содержимого памяти осуществляется итеративно

    (здесь и далее все картинки кликабельны)

    На рисунке показана область памяти, отведенная некоей виртуальной машине, расположенной на узле Node1. После запуска процесса синхронизации – все содержимое памяти передается страницами по 4Кб на целевой хост, где, предварительно, была выделена область памяти такого же объема, и содержимое записывается напрямую в память. Это – первая итерация. В процессе передачи содержимое некоторых страниц было изменено (желтые ячейки). Поэтому запускается вторая итерация, в процессе которой копируются только измененные страницы. Так как их будет значительно меньше, чем суммарный объем памяти – процесс займет намного меньше времени, и после второй итерации содержимое памяти на обоих хостах будет идентично. На самом деле, итераций может быть больше – до 10. Если достичь полной идентичности за 10 итераций не удается – процесс миграции прерывается. Это – одно из «слабых мест» Live Migration: если виртуальная машина слишком активно работает с памятью – существует теоретическая возможность, что перенести ее с помощью Live Migration будет невозможно. В этом случае надо подождать спада активности, или использовать другие методы перемещения –например, Quick Migration. Сразу же после окончания процесса синхронизации – новой виртуальной машине передается управление всеми необходимыми дисками (как VHD так и pass-through-дисками). Процесс такого «переключения» происходит практически мгновенно, TCP-соединения не успевают «отвалиться» по таймауту, и пользователи не замечают, что что-то изменилось.

    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.

    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 Cluster.

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

    4. Следует создать между узлами отдельную независимую сеть для трафика Live Migration с пропускной способностью 1Gbps и выше.

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

    6. Для использования Cluster Shared Volume все узлы кластера должны иметь одинаковую букву загрузочного раздела (например – С:).

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

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

    Помимо обязательных требований, рекомендуется:

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

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

    Так же обязательно надо учитывать, что при использовании Live Migration любые два узла кластера могут быть задействованы только в одном процессе миграции, и при этом перемещается только одна виртуальная машина. Нельзя одновременно перемещать несколько машин с одного хоста или на один хост. Это означает, что в кластере из N узлов может одновременно происходить N/2 процессов миграции.

    Основные сценарии применения

    Для чего же можно применять кластеры, и, в частности – Live Migration? Существует несколько общих сценариев.

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

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

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

    Динамическая IT-инфраструктура

    Благодаря использованию технологии Live Migration, можно сделать IT-инфраструктуру полностью динамической. Очень сильно помогут в этом другие программные продукты – Microsoft System Center Virtual Machine Manager (VMM) и System Center Operations Manager (SCOM). Они позволяют следить за загруженностью всех физических хостов в реальном времени, и, в зависимости от загруженности – перемещать виртуальные машины с более загруженных серверов на менее загруженные, распределяя, таким образом нагрузку равномерно. Возможен и другой сценарий: при низкой загруженности серверов можно автоматически перемещать виртуальные машины, запуская большее число виртуальных машин на меньшем числе физических хостов. Неиспользуемые хосты при этом выключаются, что позволяет снижать энергопотребление и требования к кондиционированию в помещении серверной. При возрастании нагрузки в «часы пик» свободные хосты могут быть снова автоматически включены, и нагрузка может быть вновь равномерно распределена по хостам.

    От теории – к практике.

    Теперь попытаемся «пощупать» Live Migration на практике: развернем кластер на настоящих серверах, создадим высокодоступную (High Available) виртуальную машину и попробуем ее мигрировать.

    Краткое описание тестовой среды

    Итак, что же мы имеем? Для работы с Live Migration развернута тестовая среда, включающая в себя:

    · Виртуальную машину, на которой поднят контроллер домена TEST.LOCAL и iSCSI Target от компании StarWind (бесплатная версия, поддерживает виртуальные диски до 2Тб)

    · Два компьютера, играющих роль узлов кластера. Каждый из них снабжен процессором фирмы Intel, удовлетворяющим требованиям для работы Hyper-V. Оба компьютера снабжены двумя сетевыми адаптерами, один из которых подключается в коммутатор, другой – соединяется с другим компьютером перекрестным патч-кордом.

    · Обычный коммутатор Gigabit Ethernet

    Всего создано два iSCSI-устройства. Одно – объемом 0,5Гб, будет использоваться в качестве кворума. Другое, 50Гб – для хранения данных. Схема тестовой среды приведена на рис.1:

    clip_image004

    Тестовая среда для развертывания кластера

    Начальные настройки узлов кластера

    В качестве узлов кластера используются два компьютера – Node1 и Node2. У каждого из них имеется по два интерфейса Gigabit Ethernet – LAN1 и LAN2. Настройки сетевых интерфейсов:
    Узел/Интерфейс IP-адрес Маска подсети Default Gateway DNS
    DC 10.0.0.1 255.0.0.0 127.0.0.1
    Node1/LAN1 10.0.0.2 255.0.0.0 10.0.0.1 10.0.0.1
    Node1/LAN2 172.16.0.1 255.255.0.0
    Node2/LAN1 10.0.0.3 255.0.0.0 10.0.0.1 10.0.0.1
    Node2/LAN2 172.16.0.2 255.255.0.0

    Оба узла (Node1 и Node2) введены в домен TEST.LOCAL.

    Итак, первое, что нам необходимо сделать – это подключить наши iSCSI LUN’ы. Для этого на первом узле заходим в Administrative Tools – iSCSI Initiator. Сервис iSCSI по умолчанию не запущен, поэтому система спросит, хотим ли мы, чтобы этот сервис запустился и стартовал автоматически. Соглашаемся. В окне настроек инициатора первое, что нам необходимо сделать – это указать, где находятся наши iSCSI- диски. Заходим на закладку Discovery, выбираем Discover Portal и вводим адрес нашей системы хранения. В данном случае, как уже было написано – это сервер DC, то есть 10.0.0.1. Если все было указано правильно – в списке порталов появится наш сервер. Если были какие-то проблемы (например, порт закрыт Firewall’ом или адрес неправильный) – выдаст сообщение об ошибке. Теперь идем на закладку Targets и видим, что у нас появились два таргета со статусом Inactive. Нужно по каждому из таргетов кликнуть и нажать Connect. В появившемся окошке оставляем все по умолчанию (имя таргета должно оставаться, и верхняя галочка должна быть включена – тогда наш диск автоматически подключится при перезагрузке ОС, см. рис. 2):

    clip_image005

    Подключение iSCSI-дисков

    Затем переходим на закладку Volumes and Devices и выбираем Auto Configure. После этого можно закрывать окно свойств инициатора нажатием кнопки OK.

    Следующим шагом нам нужно зайти в консоль Server Manager в раздел Storage – Disk Management. Если все было сделано правильно, то там появятся два новых диска и оба будут в состоянии Offline. Переводим их в Online. Затем оба диска надо проинициализировать (Initialize) и создать разделы. Мы создадим на каждом диске по одному разделу объемом на весь диск и отформатируем в системе NTFS (другие не поддерживаются Microsoft Clustering Services). Присваиваем маленькому диску букву Q: и метку Quorum, а большому – S: и Storage соответственно. Естественно, это делается для удобства. После успешного завершения все будет выглядеть как на рисунке 3

    clip_image007

    Окно оснастки управления дисками после создания разделов

    Затем надо установить роль 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 минут. Если все ОК – мы увидим что-то наподобие рис. 4.

    clip_image009

    Проверка конфигурации успешно завершена, можно собирать кластер.

    Если были какие-либо проблемы – можно посмотреть отчет (View Report) в виде веб-страницы, где будет подробно объяснено, какие тесты провалились и почему. После исправления всех проблем – надо запустить проверку заново.

    Итак, проверка успешно завершена, и можно, наконец-таки собирать кластер. В FCM выбираем Create a Cluster. Появится мастер, похожий на предыдущий. Надо выбрать наши два узла, а затем – ввести DNS-имя и IP-адрес для нашего кластера. В нашем случае – hvcluster с IP-адресом 10.0.0.10 (см. рис. 5.)

    clip_image011

    Зададим сетевое имя и 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 может использоваться только для виртуальных машин и ни для чего более (см. рис. 6).

    clip_image013

    При включении 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. Память, и все остальное – по вкусу. Но есть нюансы. Путь для сохранения файлов виртуальной машины не оставляем по умолчанию, а указываем наш кластерный диск (см. рис. 7).

    clip_image015

    Файлы виртуальной машины будем хранить на CSV.

    Размер виртуального диска желательно, во избежание конфуза, указать меньше, чем размер нашего кластерного диска. Например – 20Гб. Дальше все – по вкусу.

    Сразу же, если мы собираемся использовать миграцию, а процессоры у серверов одного производителя, но разной модели (как в нашем случае), то необходимо включить Processor Compatibility Mode. Заходим в свойства виртуальной машины (Settings), и в разделе Processor – устанавливаем галочку “Migrate to a physical computer with a different processor version” (см. рис. 8).

    clip_image016

    Включаем 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. Мы узнали, что нужно для ее использования, как происходит сам процесс миграции, и осуществили все описанное на практике. Надеюсь, что вы нашли эту статью полезной.

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

    Так же, с предыдущей статьей «Повышение надежности систем на базе виртуализации», опубликованной в сентябрьском номере «Системного Администратора», можно ознакомиться у нас на сайте.

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

Комментарии

  1. Я конечно понимаю ЭТО в журнале уровня СисАдм… Но здесь… Смотрится мягко скажем странно… Для кого эта статья? Для тех, кто не чиатет ничего, кромеэтого сайта? Таких наверное не существует.

    >ни пинг ни закачка файла, как мы видим, не прерывается
    Уж сколько раз твердили миру… Закачка при хорошим условиях выживет конечно, а вот пинг – сильно врядли. В боевых условиях с вероятностью 99%будут потери (не критичные, опять же, но будут).

    А вообще статья повторяет всё, что уже было в 55 тысячах других таких же статей про LM – от официальных манов до блогов. Не описаны даже подводные камни. Смахивает на макретинг больше, чем на техинческую статью. Моя не доволен!

  2. >Смахивает на макретинг больше, чем на техинческую статью.

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

  3. >Я конечно понимаю ЭТО в журнале уровня СисАдм… Но здесь… Смотрится мягко скажем странно…
    А чем плох уровень журнала “СА”? Я не видел например аналогичных изданий. Во всяком случае, уровень у них явно выше, чем у “Какера”.

    >А вообще статья повторяет всё, что уже было в 55 тысячах других таких же статей про LM — от официальных манов до блогов.
    Вот именно на русском такой инфы маловато. Кроме того, на момент публикации информация была актуальна. Здесь же пришлось выложить с большой задержкой – из-за требований редакции журнала.

    >Не описаны даже подводные камни.
    Чукча не читатель, чукча писатель?

    >Смахивает на макретинг больше, чем на техинческую статью.
    И где Вы здесь увидели маркетинг?

  4. >Чукча не читатель, чукча писатель?
    Чукча на техдейз внимательно слушал 😉 И с нужными людьми говорил… Не всё так радужно, как хотелось бы…

    >Смахивает на макретинг больше, чем на техинческую статью
    Эт субъективно. Имелся в виду уровень статьи.

  5. >Чукча на техдейз внимательно слушал
    ЕМНИП, вебкаст про Live Migration на techdays.ru – мой. В статье практически то же самое только в виде текста.

    >Эт субъективно. Имелся в виду уровень статьи.
    Насчет уровня статьи… Ну, да, до Русиновича, который умудрился 40 минут рассказывать про коалесцирующие таймеры – мне конечно далеко. Но тем не менее – вполне себе техническая статья, описывающая принципы работы и процесс инсталляции. А маркетинг это типа “благодаря новым технологиям Live Migration простои оборудования и TCO сокращаются в over 9000 раз! Покупайте Windows Server 2008 R2!”

    У меня к Вам встречный вопрос: чего, по-вашему, не хватает в статье?

  6. >Чукча на техдейз внимательно слушал 😉 И с нужными людьми говорил… Не всё так радужно, как хотелось бы…
    А что делать тем кто там не был? тут сказано про технологию запланированного мигрирования с одного реального сервера на другой. И в чем проблемы в данном конкретном случае, не описанные в данной статье?
    Или ты имеешь ввиду что при ВНЕЗАПНОМ падении ноды машина поднимается на другой только через резет? Так это уже совсем другой разговор, и насколько мне известно такой технологии сейчас вообще нет, ни у кого!

  7. Не хватает нового. Того, чего не было где-то еще.
    Собственно, дабы не быть голословным по поводу кол-ва материалов:
    http://www.google.com/search?hl=ru&q=Windows+Server+2008+live+migration&lr=lang_ru&aq=f&oq=
    Далее, вот яркий пример. “Migrate to a physical computer with a different processor version” – отлично, снялипоставили. А что это? Зачем? И главное чем грозит? Вы же степ-бай-степ надеюсь делали, а серьезную статью. И ограничей здесь по объемам, как в журнале, нет.

    Илья, по моему комментарии специально созданы для того, чтобы люди могли выражать своё мнение. Я по моему не наезжал, просто выразил мнение. То, что оно негативное – ну простите, уж какое есть. Что-то вот про Карманова, даже с его своеобразным ведением повествования, не нельзя сказать “боян”. Хотя пишет про всё то, про что пишут уже несколько лет. И да, я субъективен, как и все собственно.

    Ладно, на сим успокаиваюсь. Надеюсь меня верно поняли 🙂

  8. В предыдущем опечатка:
    “Вы же НЕ степ-бай-степ…..”

  9. > Далее, вот яркий пример. «Migrate to a physical computer with a different processor version» — отлично, снялипоставили. А что это? Зачем?
    Есть документ у MS, описывающий что есть PCM – объемом как несколько этих статей. Я подумал, что нет смысла замусоривать статью и просто написал, что эта галочка нужна если в серверах стоят процессоры разных моделей. Это, кстати и есть один из “подводных камней” 😉

    > Вы же степ-бай-степ надеюсь делали, а серьезную статью. И ограничей здесь по объемам, как в журнале, нет.
    Я решил сделать именно step by step. “Войну и мир” писать не хочу – статья должна быть помимо прочего – еще и легко читаема.

  10. Сравнение с VMware VMotion:

    >1. Поддерживаемые версии ОС:
    > a. Windows Server 2008 R2 64bit Enterprise Edition
    > b. Windows Server 2008 R2 64bit Datacenter Edition
    > c. Hyper-V Server 2008 R2

    VMotion может проходить между ESX и ESXi разных версий, 3.5 и 4.0 любой редакции с включенной в лицензию VMotion.

    >2. Все хосты, на которых планируется использовать Live Migration – должны являться узлами Microsoft Failover Cluster.

    Для использования VMotion НЕ требуется, чтобы хосты были в HA кластере. Более того, не требуется, чтобы они вообще были в кластере.

    >3. Microsoft Failover Clustering поддерживает до 16 узлов в одном кластере.

    В силу отсутствия требования к кластерам, VMotion может проходить между любыми двумя хостами, подключенными к vCenter – 200/300 (для 32бит и 64бит ОС для vCenter)

    >4. Следует создать между узлами отдельную независимую сеть для трафика Live Migration с пропускной способностью 1Gbps и выше.

    В ESX это рекомендуется, но не требуется.

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

    У ESX требование такое же, но лично у меня проходили миграции Xeon Opteron без каких-либо проблем.

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

    Для ESX это рекомендуется, но не требуется.

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

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

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

    Такого ограничения нет у ESX 🙂

  11. Александр, на русском материалов по виртуализации и живой миграции очень даже много. Если, конечно, не считать, что у MS самая живая миграция, а ESX и Xen делают все как-то совсем иначе.

    >Или ты имеешь ввиду что при ВНЕЗАПНОМ падении ноды машина поднимается на другой только через резет? Так это уже совсем другой разговор, и насколько мне известно такой технологии сейчас вообще нет, ни у кого!

    VMware Fault Tolerance о чем-то Вам говорит? А Marathon EverRun?

  12. >такой технологии сейчас вообще нет, ни у кого!

    >VMware Fault Tolerance о чем-то Вам говорит?

    Пока Майкрософт не выпустит Hyper-V R5 с Hyper-V Fault Tolerance такой технологии не сущетсвует в природе))))))))))))))) И точка)

  13. >При этом во время миграции ни пинг ни закачка файла, как мы видим, не прерывается.
    ОФИЦИАЛЬНО сказано (и на TechNet Весна 2009 показано), что один пинг может потеряется. НО меня больше интересует другие вопросы:
    1. Потеряется ли коннект клиента 1С 8,1?
    2. Выживет ли терминальная сессия пользователя без дисконектов?
    3. Сможет ли SCVMM сделать автоматом миграцию высоконагруженного сервера (ограничение в 10 итераций синхронизаций памяти) и какие есть варианты повышения вероятности успешного исхода?

  14. Anton Zhbankov Вопрос по теме, есть ли гденибудь вебкаст с демонстрацие работы VMware Fault Tolerance ???? Ну или видео какое нибудь.

  15. mikas, отвечу по VMware
    1. нет
    2. да
    3. VMware может

    Илья, http://download3.vmware.com/vdcos/demos/FT_Demo_800x600.html

  16. Ну блин началось.. ESX-ESX… ESX – такая же какашка, уж простите… Я вот щаз с ним работаю плотно – нихрена не панацея, точно также иногда падает ни с того ни с сего. С бакапом и агентом часто непонятности.

    >Fault Tolerance
    А вы её видели живьем? Или хотя бы читали серьезные доклады? Это ЧИСТЫЙ маркетинг, ничего более. Эта фишка работает только на невысоко нагруженных безтранзакционных системах. Внимание, вопрос – у кого такие есть в продакшине?

  17. FreemanRU, не обижайся, но ты мне Валерию Ильинишну иногда напоминаешь 🙂

  18. >ESX-ESX… ESX — такая же какашка, уж простите… Я вот щаз с ним работаю плотно — нихрена не панацея, точно также иногда падает ни с того ни с сего.

    “У меня не падает, что я делаю не так?” (с)
    Подозреваю, дело в прокладке.

    >С бакапом и агентом часто непонятности.

    Что там непонятного? Все отлично работает.

    >А вы её видели живьем? Или хотя бы читали серьезные доклады?

    Видел, читал. Кстати, поделитесь ссылкой на “серьезный доклад”, пожалуйста.

    >Это ЧИСТЫЙ маркетинг, ничего более.

    Возможность кластеризовать системы, которые кластеризовать ни на уровне приложения, ни на уровне ОС нельзя – это чистый маркетинг? Спасибо, Вы открыли мне глаза!

    >Эта фишка работает только на невысоко нагруженных безтранзакционных системах.

    По последним отчетам, которые я видел, производительность процессоров сейчас такова, что Exchange в FT машине (= 1 процессор) на Nehalem держит 1500-2000 почтовых ящиков. Это много или мало?

    Да, высоконагруженные многопроцессорные системы – плохие кандидаты на кластеризацию при помощи FT. Но они, строго говоря, плохие кандидаты на виртуализацию вообще.

    У меня есть в production критические системы со средним уровнем загрузки процессора около 400 MHz. Забавно, но на 3GHz процессоре, с учетом 10% накладных расходов на FT, получается утилизация 15%. Т.е. я спокойно мог бы поднять нагрузку в 6 раз без того, чтобы упереться в процессор, если бы я использовал на этих машинах FT.

    На всякий случай, причина НЕиспользования FT – не слабость FT или что-то еще, а модель процессора. На текущий момент моя инфраструктура VMware работает на Xeon 5365, которые FT просто не поддерживают.

  19. >У меня не падает, что я делаю не так
    Сколько хостов?

    По поводу FT – дело не в процессоре. Дело в памяти и в транзакциях. Н-р тот же Exchange или SQL с 16тью гигами памяти. Постоянный страничный обмен, всё кладется в кэш. И тут случается то, что никогда не хочется видеть ни один админ – выгарает банк памяти. Или чип. И в памяти оказываются сбойные значение. Хост-машина тут же “вешается”. Кто даст гарантии в том, что:
    1. Вся память корректно скопируется на второй хост?
    2. На второй хост попадет валидная память?

    Что касается сбоев ВМвари, то вот мой любимый:
    http://kb.vmware.com/kb/1004797
    Элементарная конечно… НО 🙂 испортила жизнь многим моим знакомых админам. Причем как замечено делать для этого ничего особого не надо.
    И это только один, таких вот подарков – масса. Не бывает идеальных продуктов, везде есть свои особенности.
    Про бакап тоже можно сказать кое-что интересное – н-р не всегда срабатывает VSS, при большой нагрузке на хост. Средства мониторига и их цена тоже “на высоте”, причем размер последнего не всегда соответсвует кач-ву первого.

  20. >Валерию Ильинишну иногда напоминаешь
    Просто очень не люблю, когда начинаются объяснения “а вот этот продукт просто супер, ну нет у него конкуретнов и никогда не будет, потому что ОН МЕГА”. Напоминает “красноглазиков” (с)

  21. >Хост-машина тут же «вешается». Кто даст гарантии в том, что:
    >1. Вся память корректно скопируется на второй хост?

    Память копируется один раз, при включении FT. Далее машины работают независимо друг друга, память не синхронизируется, передаются только недетрминированные события. И между прочим, про FT прямо говорится, что если основаня ВМ падает в BSOD, то и теневая тоже выпадет.

    Так Вы тут кому глаза-то пытаетесь открыть?

    >2. На второй хост попадет валидная память?

    Она вообще туда не попадает.

    >Что касается сбоев ВМвари, то вот мой любимый:
    >kb.vmware.com/kb/1004797

    (с интересом) А в чем юмор, расскажите пожалуйста?

    >Не бывает идеальных продуктов, везде есть свои особенности.

    А масло-то оказывается, масляное! А вода мокрая! Эврика!

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

    Ничего, что VSS – это винда, а не VMware?

    >Средства мониторига и их цена тоже «на высоте», причем размер последнего не всегда соответсвует кач-ву первого.

    Этим занимаются сторонние фирмы. Совершенно согласен насчет цены, но опять же, при чем тут VMware?

  22. >>Валерию Ильинишну иногда напоминаешь

    >Просто очень не люблю, когда начинаются объяснения «а вот этот продукт >просто супер, ну нет у него конкуретнов и никогда не будет, потому что ОН >МЕГА». Напоминает «красноглазиков» ©

    Нееее. Ты в каментах прошелся по всем :))) И по хайпер-ви и по вмваре. “Все казлы! У всех говно!” 😉

  23. >Сколько хостов?

    Пока 10. 150+ ВМ, планируется увеличение минимум вдвое.

  24. /me задумчиво
    Как я люблю статьи по hyper-v) Душевные обсуждения)

  25. Душевнее только по сертификации 🙂

  26. Я прочитал все 27 комментариев.

    Вкратце – о чем разговор?

    А то люди интересуются, но не могут уловить суть события.

    Желательно в простых словах, для рабочего класса в моём лице.

  27. “И тут пришел [s]поручик Ржевский[/s]Руслан Карманов и начался настоящий [s]разврат[/s]срач”

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

    вот как-то так в общем 🙂

  29. >Виртуализация — гавно. Что хайпер-ви, что вмваре.
    >Виртуализация — для нищебродов, у кого денег на железо нет

    Убить всех людей! Слава роботам!

  30. Дискуссия упёрлась в алмазную сутру российского IT: “всё говно, за исключением мочи”.

    Предлагаю на этой торжественной ноте завершить технологическую часть дискусии. Обмен номерами KB с хватанием за грудки “а ты, ты, морда, читал, а, в глаза смотри, в глаза, что, а?” напоминает бокс по переписке. Этот вид спорта не понимаю совсем. Обязательно чем-то меряться? Ну у VMWare номера KB семизначные, а у Microsoft – шестизначные. Microsoft слил по полной, короче. Кого поздравлять, я путаюсь несколько, пальцем покажите, пожалуйста.

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

  31. А мне кажется нормально так поговорили. Зато понятно, что нет гор золотых. И именно в таких вот обсуждениях, рождается полезная информация.

  32. Общаясь с коллегами-айтишниками, заметил эффект “подсаживания”. Если первой серьезной системой виртуализации в практике была Hyper-V, то скорее всего она и будет в дальнейшем предпочтительной для данного конкретного специалиста. Точно также можно сказать и о ESX/vSphere. Айтишники от добра добра не ищут.

    А дальше начинается нахваливание своего болота. Приверженец Hyper-V говорит, что плюсов миллиард – цена, встроенность в Windows, привычный интерфейс, “самая живая” миграция т.п. Приверженец продуктов VMWare также хвалит свою систему – цена(!), высочайшая плотность размещения ВМ в памяти, действительно живая миграция, fault tolerance, и так далее.

    Ну в конце концов, мы же тут все взрослые люди – давайте просто достанем и померяемся! 🙂

  33. >заметил эффект «подсаживания».

    Это не откровение, а давно известный факт. И это нормально.

  34. >Приверженец продуктов VMWare также хвалит свою систему — цена(!), высочайшая плотность размещения ВМ в памяти, действительно живая миграция, fault tolerance, и так далее.

    Цена чего, извините? Гипервизора? Я предпочитаю считать стоимость инфраструктуры (железо, сетевые порты, дисковые массивы, ОС в гостевых) и приложений. Ценовой расклад при росте размера инфраструктуры может меняться очень забавно.

    Я приверженец не продуктов VMware, а хороших продуктов. У Hyper-V же пока нос не дорос, и мне лично крайне неприятна маркетинговая политика MS в отношении него, не люблю, когда мне настойчиво пытаются что-то впарить методами лохотрона.

  35. Антон, об этом я и говорю. МС утверждает, что Hyper-V дешевле. VMWare предпочитает считать стоимость владения. Поэтому аргумент “цена” говорит в пользу обоих систем, просто разный смысл в него вкладывается 🙂

    По поводу впаривания опять же соглашусь. Совести всё-таки должно быть побольше.

  36. >Совести всё-таки должно быть побольше.
    Рассмотрим ситуацию: вы директор фирмы. Вы продаете помидоры. Они слегка не спелые, но есть можно – не отравишься. Да и стоят они в два раза дешевле, чем спелые и красивые помидоры у конкурента. Так вот, вы директор этой самой фирмы. И ваш менеджер Вася продает в месяц помидоров на 10млн р. А менеджер Петя продает их всего на 10тр. потому как каждому покупателю объясняет что есть помидоры “лучше и красивше”.
    Господа, будь вы директором, вы бы какого менеджера уволили нахрен? 😉

  37. Антон (36):
    > Цена чего, извините? Гипервизора? Я предпочитаю считать стоимость инфраструктуры (железо, сетевые порты, дисковые массивы, ОС в гостевых) и приложений.

    Хмм… А что с ценой инфраструктуры? Железо одно и то же. ОС в гостевых – если и там и там будут винды – одна и та же. Более того, в зависимости от версий хостовых виндов – есть определенное кол-во бесплатных лицензий на гостевые винды. Я не говорю что софт с Hyper-V обойдется намного дешевле, т.к. нет лицензирования по кол-ву процессоров (кроме версии Datacenter) и нет лицензирования отдельных фич. Не говоря уж про то, что Hyper-V Server R2 умеет и кластеры и Live Migration, в отличие от ESXi.

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

  38. >Железо одно и то же.

    С учетом Memory Overcommitment у ESX на том же железе можно разместить в 1.2-1.4 раза больше ВМ. Что приводит при достаточном размере инфраструктуры к меньшему количеству серверов, меньшему количеству портов, и меньшему количеству лицензий.

    >Не говоря уж про то, что Hyper-V Server R2 умеет и кластеры и Live Migration, в отличие от ESXi.

    Я разве где-то говорил, что ESX всегда выгоднее? Напротив, моя позиция очень проста: на малых инфраструктурах Heper-V R2 экономически весьма неплохо выглядит, особенно с набором функций. На больших ему делать нечего, пока не дорос.

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

    Александр, я что-то пропустил и Вы уже работаете в маркетинге MS?

  39. > Вы продаете помидоры. Они слегка не спелые, но есть можно — не отравишься. Да и стоят они в два раза дешевле, чем спелые и красивые помидоры у конкурента.

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

    Если же я буду заставлять менеджеров продавать тухлые помидоры в элитный ресторан, то идиот – я, а не менеджер.

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

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

  41. > С учетом Memory Overcommitment у ESX на том же железе можно разместить в 1.2-1.4 раза больше ВМ.
    Memory Overcommitment вообще спорная вещь. Это – “предельный режим работы”, который должен использоваться только в нештатных ситуациях. Использовать Overcommitment постоянно – может быть чревато падением производительности. В конце концов, оперативная память сейчас очень дешева, и добавить в сервер лишних 10 гигабайт – можно практически не напрягаясь, что вообще сводит на нет полезность этой фичи.

    > На больших ему делать нечего, пока не дорос.
    Пивоваренная компания “Балтика” – это большие или маленькие?

    > Александр, я что-то пропустил и Вы уже работаете в маркетинге MS?
    Увы и ах 🙂 Вот поэтому я и не понял, почему здесь вообще зашла речь о маркетинге? Статья-то сугубо техническая.

  42. >Покупатель, тебя обманули — сам виноват, плохо смотрел.
    Это бизнес, ничего личного 🙂

    Касаемо MS, я не могу объявить эту компанию в том, что она “продает тухлые помидоры” под видом спелых. А вы можете? Если да – то приведите пример.

  43. >Memory Overcommitment вообще спорная вещь. Это — «предельный режим работы», который должен использоваться только в нештатных ситуациях.

    Напомню, Memory Overcommitment – это не только balloon, это еще и Transparent Page Sharing. Совершенно нормальный режим работы.

    >Использовать Overcommitment постоянно — может быть чревато падением производительности.

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

    >В конце концов, оперативная память сейчас очень дешева, и добавить в сервер лишних 10 гигабайт — можно практически не напрягаясь, что вообще сводит на нет полезность этой фичи.

    Какая знакомая фраза.

    1) Память для брэндовых серверов не настолько дешева, как обычная десктопная. Особенно модули большой емкости.
    2) А что делать с серверами, в которых кончились слоты под память? В этом случае остается только выкинуть всю память, которая там уже стоит, и поставить новые дорогие модули.

    >Вот поэтому я и не понял, почему здесь вообще зашла речь о маркетинге?

    Этот комментарий был не к статье, а скорее так, мысли вслух в процессе беседы.

    >Касаемо MS, я не могу объявить эту компанию в том, что она «продает тухлые помидоры» под видом спелых.

    Лично я наблюдал на презентациях Hyper-V представителей MS со слайдами, в которых была явная ложь о ESX, не говоря уже о “корректности” сравнений.

    Если перейти на овощные аналогии, то Hyper-V вполне нормальный помидор, только его пытаются продать под видом апельсина, а персик при этом почему-то называют огурцом.

  44. > 1) Память для брэндовых серверов не настолько дешева, как обычная десктопная.
    В сравнении со стоимостью всего остального железа – достаточно дешевая.

    > А что делать с серверами, в которых кончились слоты под память?
    Вообще обычно еще на этапе проектирования известно, сколько виртуальных машин будет запущено на сервере и сколько памяти им потребуется. И кроме того, опять же на этапе проектирования надо делать какой-то запас если не по объему памяти, то хотя бы по количеству слотов.

  45. >В сравнении со стоимостью всего остального железа — достаточно дешевая.

    Достаточно дешевая – это сколько? Можно в цифрах?

    И еще – эти цифрв будут выглядеть “достаточно дешево” для генерального, который будет подписывать бюджет апгрейда?

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

    Такое впечатление, что Вы живете в идеальном мире.
    Если мы говорим о разовом проекте, то да, это известно. В общем случае нет. В общем случае у нас есть некий ресурс платформы, а многочисленные отделы просят еще один сервер, а потом еще один, и еще два, и так далее.

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

    В некоторых компаниях время от выставления спецификации до приезда сервера составляет полгода и более в силу бюрократических проволочек и 2х месяцев поставки. За эти полгода, бывает, что-то внедряется. А бывает, что в следующея плановой закупке вычеркивают железо и лицензии на расширение инфраструктуры. И с этим как-то надо жить.

    Memory Overcommitment, и в особенности Transparent Page Sharing – это инструкмент, который Вы можете использовать или не использовать. Инструмент крайне полезный, хотя и имеющий некоторые особенности, о которых надо знать. Что самое смешное, у VMware это идет бесплатно, в любой редакции, включая Free ESXi.

    В сентябре проводил наш местный местечковый интегратор круглый стол по виртуализации совместно с локальным представительством MS, гордо рассказывали о проекте по виртуализации. Они целых три виртуальных сервера на Hyper-V сделали, контроллер домена, файл-сервер и 1С. Да, здесь ни Memory Overcommitment не нужен, ни DRS, ни еще что-либо.

  46. Забавно, по мотивам “Memory overcommitment не нужен и опасен” возникла ассоциация.

    Год назад представители Microsoft на всех уровнях утверждали, что live migration нужна буквально паре процентов пользователей, остальным quick migration достаточно, даже и не заметят. Технолгия Live Migration на тот момент была у *всех* вендоров платформ виртуализации x86 кроме MS.
    Hyper-V R2 вышел и тут же фанфары – ура, у нас технологический прорыв!!! Все скорее смотрите как у нас круто!

    Memory Overcommitment в виде Balloon появился в Xen, у VMware c
    Memory Overcommitment все вообще лучше всех. У кого нет? Правильно, у MS.

    Ждем, когда MS это реализует и любители MS тут же начнут рассказывать о новом технологическом прорыве в индустрии.

  47. > И еще — эти цифрв будут выглядеть «достаточно дешево» для генерального, который будет подписывать бюджет апгрейда?
    Думаю, что в сравнении с лицензиями на VMWare Infrastructure – таки будут.

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

    Почитайте на сайте MS кейсы – там встречаются и более крупные внедрения.

    > Год назад представители Microsoft на всех уровнях утверждали, что live migration нужна буквально паре процентов пользователей

    На самом деле так оно и есть. Заказчиков, которым реально нужна работа 24х7х365 с невозможностью остановки даже на минуту – их и правда не так и много. А готовых заплатить за это соответствующие деньги – еще меньше.

  48. >Думаю, что в сравнении с лицензиями на VMWare Infrastructure — таки будут.

    Думаете, или все таки аргументировать будете фактами?

    >Почитайте на сайте MS кейсы

    100-тонный аргумент.

    >На самом деле так оно и есть.

    Т.е. Live Migration технология бесполезная?

  49. >> И еще — эти цифрв будут выглядеть «достаточно дешево» для генерального, который будет подписывать бюджет апгрейда?

    >Думаю, что в сравнении с лицензиями на VMWare Infrastructure — таки будут.

    Не понял, зачем сравнивать теплое с мягким?

  50. > Думаете, или все таки аргументировать будете фактами?
    Думаю.

    > 100-тонный аргумент.
    А почему бы и нет?

    > Т.е. Live Migration технология бесполезная?
    Не бесполезная, просто не всем она реально необходима.

  51. У меня только один вопрос остался – почему, если VMware всё так хорошо и замечательно, они так экономят всем деньги, они постепенно теряют рынок, причем даже в крупных внедрениях? Рынок не обманешь. И когда ИТ-директор видит счет на решение вмвари и решение хипер-ви, он выбирает необходимое и _достаточное_ в своем случае. Да, в 20-30% (количественных внедрений) это варя. В остальных случаях – Хипер-ви. В денежном эквиваленте трудно считать, ибо если MS продает по довольно фиксированным ценам, то варя умеет “проседать”.

  52. >почему

    Наверно потому, что раньше на рынке виртуализации не было такого игрока как майкрософт. Игрока который знает как с пятой попытки сделать из “г” конфетку, но при этом еще на второй попытке успеть продать миллионы копий.

  53. >Да, в 20-30% (количественных внедрений) это варя. В остальных случаях — Хипер-ви.

    Источник не затруднит? А то Gartner отдает VMware 80% рынка виртуализации x86, если не ошибаюсь.

  54. > А то Gartner отдает VMware 80% рынка виртуализации x86, если не ошибаюсь.

    Тут даже я не выдержал, и цинично заржал. Проценты рынка виртуализации – это что? Количество проданных копий ПО, физических хостов, виртуалок?

  55. > А то Gartner отдает VMware 80% рынка виртуализации x86, если не ошибаюсь.
    Ну вообще в приличном обществе на Gartner и IDC ссылаться как бы не принято. Уж больно сильно у них результаты исследований кореллируют с тем, кто их заказывал.

  56. Нда… ну вы тут и развели базар. Многа Буков, НИАСИЛИЛ.

  57. Какие люди и без охраны!(с)

    “Ниасилил” – надеюсь это не про саму статью? :)))

  58. А я вот АСИЛИЛ 🙂 Базар интересный конечно получился, ничего не скажешь. У самих Hyper-V, начиная с R2 перевели много из продуктива на него, пока полет нормальный. Пару моментов:
    1) “Следует создать между узлами отдельную независимую сеть для трафика Live Migration с пропускной способностью 1Gbps и выше.” – я еще не экспериментировал с конфигурацией без отдельной сетки, но вроде читал что это только рекомендуемая конфигурация, но должно работать и с одной. Поправьте если не так.
    2) Насчет 10 итераций для памяти при переносе VM – это для меня была практически единственная новая инфо из статьи. Так вот, по личному опыту – достаточно сильно нагруженный Sharepoint-портал (примерно 60% average CPU для 4-х ядер и кушает около 6 Гб памяти из 8 выделенных) – переезжал уже несколько раз, и вроде пока успешно всегда.

  59. Оффтоп
    to Ruslan V. Karmanov:
    Уважаемый Руслан!
    Продолжение вашего сериала про AD будет или все умерло

  60. > «Следует создать между узлами отдельную независимую сеть для трафика Live Migration с пропускной способностью 1Gbps и выше.»
    Это как бы настоятельная рекомендация. Потому что если между узлами будет 10-мегабитный линк, да еще и забитый напрочь – процесс миграции может занять больше времени, а может и вообще не пройти (вспоминаем про 10 итераций).

    Что касается миграции нагруженных серверов – ведь синхронизация памяти проходит инкрементно, и с каждой итерацией копируется все меньше и меньше инфы. Так что 10 хватает практически всегда, я еще ни разу не видел чтобы не хватило. Теоретически, если на виртуалке будет какая-нить бооольшая БД, и будет запущен какой-нить суперсложный OLAP-отчет… Но такие сервера вообще не рекомендуют виртуализировать 🙂

  61. К слову о “шоколадности” VMware, как вам эта цитата:

    Как уже сообщалось, компания VMware выпустила Update 1 для виртуальной инфраструктуры VMware vSphere 4.0 в части хостов VMware ESX и сервера VMware vCenter. Обновить хост-серверы ESX можно с помощью продукта VMware Update Manager, однако это чревато негативными последствиями, описанными в KB 1016070.
    Проблема касается хост-серверов ESX с установленными сторонними агентами производителей оборудования и описывается следующими симптомами:
    1. VMware Update Manager прекращает обновление на ESX 4 Update 1 и останавливается на 33%.
    2. После перезагрузки VMware ESX выпадает в purple screen с сообщением:
    COS Panic: Int3 @ mp_register_ioapic
    Проблема в том, что после перезагрузки хоста VMware ESX 4 с неудачным обновлением Update 1, вам придется переустанавливать ESX, что приведет к потере виртуальных машин на локальных datastores. Чтобы этого не произошло, необходимо отключить все сторонние агенты на ESX перед обновлением до Update 1. Если вы уже обновились, но не перезагружали хост – обратитесь в техническую поддержку VMware.

    И это пропагандируется как платформа виртуализации для крупного бизнеса ??? Я в шоке.

  62. > И это пропагандируется как платформа виртуализации для крупного бизнеса ???

    А BSOD’ы после обновления драйверов лучше? 🙂
    Да, расскажите нам, что майкрософт тут ни при чем, что драйверы пишутся сторонними разработчиками. А потом прочитайте свой пост еще раз:
    > необходимо отключить все сторонние агенты на ESX перед обновлением

    Шок в крупном бизнесе – очень плохая примета. Берегите нервы.

  63. >И это пропагандируется как платформа виртуализации для крупного бизнеса ??? Я в шоке.

    От ща придет Жбанков, да задаст тебе перцу!))))

  64. 64
    > А BSOD’ы после обновления драйверов лучше?

    Я последний раз видел BSOD году так в 2000-2001 из-за кривых дров USB-модема. На серверах же, особенно на брэндовых – я ни разу не видел BSOD из-за дров. Крупные вендоры обычно очень серьезно подходят к написанию дров и к тестированию дров и железа, и при этом очень тесно сотрудничают с самой MS. Конечно, если Вы решите собрать сервер из нонеймовского китайско-корейского железа – то вы ССЗБ.

  65. > если Вы решите собрать сервер из нонеймовского китайско-корейского железа — то вы ССЗБ

    С этим никто не спорит. Как и в случае установки сторонних агентов на ESX 🙂

  66. Блог очень понравился. Так держать!!!

  67. @7

    “Migrate to a physical computer with a different processor version» — отлично, снялипоставили. А что это? Зачем? И главное чем грозит?”

    Если галочка снята и процессоры разные (а производитель один) – не будут работать Live Migration и Quick Migration.

  68. Все зависим от сотрудников, здесь они достойные фирма ремонт холодильников .Выезд прямо на квартиру

  69. А коли уж речь за CSV тома зашла, то может ли кто-нибудь из microsoft адептов, находящихся здесь, подсказать – чем обусловлена необходимость размещать тома CSV именно на SAS дисках? СХД нет и не предвидится, а хотелось на трех серверах и SATA дисках сделать кластеризацию, но…