четверг, 9 октября 2008 г.

VMware infrastructure 3 vs Xen - первая проба виртуализации (ч.3)



(Часть 2)

Начинаем экспериментировать с VMware:

На одной из нод vmware кластера было отключено питание через iLO карту. Сбой ноды был зафиксирован в течении 1-2х минут. После чего виртуальная машина, которая находилась на отключенной ноде, была перезапущена "с нуля" на оставшейся ноде. Т.е. при физическом падении ноды все виртуальные машины, выполняющиеся на ней, будут перезапущены. С точки зрения конечного пользователя - хост был перезагружен.

После восстановления питания нода поднялась достаточно быстро - в течении 1-2х минут, после чего начался процесс миграции виртуальной машины "на старое место". В момент миграции ОС в виртуальной машине была доступна, однако обнаружилась неприятная вещь - в какой-то из моментов миграции работа практически была остановлена, отклик на пинги вместо обычных 170-200 мс достигал 2 секунд и более! Справедливости ради стоит отметить, что такие большие задержки наблюдались только около 15-20 сек и виртуальная машина мигрировала без перезагрузок, как и было обещано производителем.

Ладно. Теперь попробуем миграцию виртуальной машины "по команде". Как выяснилось (при проходе соотвествующего визарда), что возможна миграция в режимах High и Low priority. High подразумевает, что виртуальная машина будет постоянно доступна. При проведении эксперимента так и оказалось - была очень кратковременная (1-2 сек) задержка (вроемя отклика возрасло приблизительно на 300 мс). Low priority - работает по остаточному принципу и не обещает, что при переносе не будет кратковременных остановов виртуальной машины.

Играемся с миграцией далее. На этот раз у нас в кластере три виртуальных машины. Причем одной выделено 512Мб RAM, второй 3Гб, третьей - почти 4Гб. Останавливаем одну ноду. Упс! Вместе с ней остановилась и одна виртуальная машина (3Гб RAM), которая на этой ноде и выполнялась.

Строго говоря, ничего удивительного в этом нет - у оставшейся ноды просто не хватило ресурсов (оперативной памяти), поэтому миграция оказалась неудачной.

Но главная неприятность оказалась впереди. При включении ноды вдруг выяснилось, что HA кластер развалился! Нода, с которой не удалась миграция, сообщила об ошибке: HA agent has error. В логах зафиксирован останов HA кластера незадолжно перед этим: HA cluster disabled.

Сделал reconfigure HA cluster на этой ноде - кластер восстановился.

Я, конечно, понимаю, что миграция была невозможна. Но почему развалился HA кластер? почему система не восстановила свое предыдущее состояние? Что-то ребята из VMware не доработали.


6 комментариев:

  1. а кто/что выступает в качестве распределенной файловой системы для кластера вцелом?

    ОтветитьУдалить
  2. Я использовал VMFS3 (это родная FS от VMware), раздел находился на SAN storage.

    Вообще-то ESXi (и, по-видимому, ESX) сервер весьма беден на поддержку FS
    Как оказалось, оно знает всего-навсего VFAT и свою VMFS. Даже ОС ставится на VFAT разделы! Я был неприятно удивлен.

    Правда, VMFS3 оказалась кластерной, что в дальнейшем позволило построить "псевдокластер" (см. http://localhost/other-any/17.html )

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

    ОтветитьУдалить
  3. Не пнятно в чем разница между высокой и низкой миграцией?

    ОтветитьУдалить
  4. а когда будет продолжение статьи?

    ОтветитьУдалить
  5. К сожалению, практически не могу уделить времени :(

    Тут еще и ESXi4 уже выпустили, тоже довольно интересно, надо пробовать.

    ОтветитьУдалить