(Часть 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 не доработали.
а кто/что выступает в качестве распределенной файловой системы для кластера вцелом?
ВідповістиВидалитиЯ использовал VMFS3 (это родная FS от VMware), раздел находился на SAN storage.
ВідповістиВидалитиВообще-то ESXi (и, по-видимому, ESX) сервер весьма беден на поддержку FS
Как оказалось, оно знает всего-навсего VFAT и свою VMFS. Даже ОС ставится на VFAT разделы! Я был неприятно удивлен.
Правда, VMFS3 оказалась кластерной, что в дальнейшем позволило построить "псевдокластер" (см. http://localhost/other-any/17.html )
Постараюсь найти время и изложить, как оно сейчас работает (уже реально в продакшн).
Не пнятно в чем разница между высокой и низкой миграцией?
ВідповістиВидалитиSorry, не понял вопроса.
ВідповістиВидалитиа когда будет продолжение статьи?
ВідповістиВидалитиК сожалению, практически не могу уделить времени :(
ВідповістиВидалитиТут еще и ESXi4 уже выпустили, тоже довольно интересно, надо пробовать.