![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Live migration гостевого кластера
Oct. 25th, 2013 11:07 amКоллеги, только не обзывайтесь сразу извращенцами.
Нужен совет, возможно на уровне бреда.
Исходная позиция - виндовый кластер, собранный из пяти физических хостов. На нём поднят гостевой кластер, собранный из двух нод. В обе ноды прокинута фибра. Есть и другие виртуалки с адаптерами fibre channel. Понятно, что hyper-v 2012.
Запускаем live migration для рядовой виртуалки с фиброй. Миграция проходит отлично, ошибок нет.
Запускаем live migration для ноды гостевого кластера. Нода спокойно переезжает. Через пять минут в логе system начинают сыпаться варнинги NTFS на фибровые диски, а именно:
The system failed to flush data to the transaction log. Corruption may occur in VolumeId: F:, DeviceName: \Device\HarddiskVolume5.
({Device Busy}
The device is currently busy.)
Event ID: 140
Для конечных пользователей этот варнинг череповат недоступностью или медленной доступностью файловых дисков. Тех самых, которые прокинуты по фибре в гостевой кластер.
После ребута ошибки пропадают.
Подобное поведение характерно для переезда любой ноды кластера на любой хост.
Если вместо live использовать quick migration, ошибок не наблюдается, вне зависимости от того, просто выбрали квик, остановили или погасили ноду.
Также дважды было замечено следующее: после live migration на ноде останавливается кластерная служба с отлупом на то, что недоступна вторая нода. Вторая в это время перехватывает witness и ругается на то что лежит первая нода. Опять же через пять минут поднимается первая.
Сами понимаете, что с таким поведением вообще несколько пропадает смысл в кластере.
При этом я не уверена, что эта проблема появилась именно после миграции. Но после миграции появляется 100%.
Завтра буду поднимать тестовый гостевой кластер.
Резюмирую:
Исключительно в связке live migration + гостевой кластер + фибра наблюдаются проблемы со стороны дисков.
Отдельно live migration виртуалок, отдельно миграция гостевого кластера без прокинутых дисков, отдельно миграция виртуалок с фиброй вне кластера работает без проблем.
Теперь, внимание, вопрос.
У кого, блять, какие идеи!?
Нужен совет, возможно на уровне бреда.
Исходная позиция - виндовый кластер, собранный из пяти физических хостов. На нём поднят гостевой кластер, собранный из двух нод. В обе ноды прокинута фибра. Есть и другие виртуалки с адаптерами fibre channel. Понятно, что hyper-v 2012.
Запускаем live migration для рядовой виртуалки с фиброй. Миграция проходит отлично, ошибок нет.
Запускаем live migration для ноды гостевого кластера. Нода спокойно переезжает. Через пять минут в логе system начинают сыпаться варнинги NTFS на фибровые диски, а именно:
The system failed to flush data to the transaction log. Corruption may occur in VolumeId: F:, DeviceName: \Device\HarddiskVolume5.
({Device Busy}
The device is currently busy.)
Event ID: 140
Для конечных пользователей этот варнинг череповат недоступностью или медленной доступностью файловых дисков. Тех самых, которые прокинуты по фибре в гостевой кластер.
После ребута ошибки пропадают.
Подобное поведение характерно для переезда любой ноды кластера на любой хост.
Если вместо live использовать quick migration, ошибок не наблюдается, вне зависимости от того, просто выбрали квик, остановили или погасили ноду.
Также дважды было замечено следующее: после live migration на ноде останавливается кластерная служба с отлупом на то, что недоступна вторая нода. Вторая в это время перехватывает witness и ругается на то что лежит первая нода. Опять же через пять минут поднимается первая.
Сами понимаете, что с таким поведением вообще несколько пропадает смысл в кластере.
При этом я не уверена, что эта проблема появилась именно после миграции. Но после миграции появляется 100%.
Завтра буду поднимать тестовый гостевой кластер.
Резюмирую:
Исключительно в связке live migration + гостевой кластер + фибра наблюдаются проблемы со стороны дисков.
Отдельно live migration виртуалок, отдельно миграция гостевого кластера без прокинутых дисков, отдельно миграция виртуалок с фиброй вне кластера работает без проблем.
Теперь, внимание, вопрос.
У кого, блять, какие идеи!?
При миграции виртуалок (хоть live, хоть quick) столкнулась со следующей ошибкой: миграция не идёт, в информации о виртуалке следующее:
The operation did not complete on resource virtual machine.
Оказалось, compability забыли поставить галку Migrate to a physical computer with a different processor version.
Погасить виртуалку, поставить галочку, стартовать, мигрировать.
The operation did not complete on resource virtual machine.
Оказалось, compability забыли поставить галку Migrate to a physical computer with a different processor version.
Погасить виртуалку, поставить галочку, стартовать, мигрировать.
Что-то на меня пятница странно действует.
Настроила SAN на hyper-v, прокинула fibre channel виртуалке, отрезала lun на полке.
Стартую виртуалку, а она не поднимается с отлупом synthetic fibrechannel port error \\\ creation failed with a NPIV error \\\бла-бла-бла \\\ NPIV virtual port operation on virtual port (XXXXX) failed with an error. The operation is not supported by the fabric.
Туплю секунд двадцать. Потом начинаю хихикать. Забыла, что полка тупая, а fc-свича нет. Презентовала хосту, прокинула виртуалке и только тут поняла что не отрезала под базу для wsus.
Надо сказать, что после года работы исключительно с hyper-v (я поклонник сферы, щупала xen) я перестала понимать холивары вроде "Сфера говно, даешь hyper-v" или "hyper-v ацтой, сфера рулит". Таки для каждой задачи свой продукт, что-то где-то лучше, что-то хуже. А hyper-v на 12-м мне вообще нравится.
Настроила SAN на hyper-v, прокинула fibre channel виртуалке, отрезала lun на полке.
Стартую виртуалку, а она не поднимается с отлупом synthetic fibrechannel port error \\\ creation failed with a NPIV error \\\бла-бла-бла \\\ NPIV virtual port operation on virtual port (XXXXX) failed with an error. The operation is not supported by the fabric.
Туплю секунд двадцать. Потом начинаю хихикать. Забыла, что полка тупая, а fc-свича нет. Презентовала хосту, прокинула виртуалке и только тут поняла что не отрезала под базу для wsus.
Надо сказать, что после года работы исключительно с hyper-v (я поклонник сферы, щупала xen) я перестала понимать холивары вроде "Сфера говно, даешь hyper-v" или "hyper-v ацтой, сфера рулит". Таки для каждой задачи свой продукт, что-то где-то лучше, что-то хуже. А hyper-v на 12-м мне вообще нравится.
Интересная особенность hyper-v 2012
Jul. 22nd, 2013 05:27 pmКоллеги, такое дело.
Сервер 2012, роль hyper-v, failover cluster.
Виртуалки лежат, понятно, на кластеризованном диске.
Все ISO - на обычном диске D.
Ставим виртуалки A и B. Все с ISO.
Кластеризуем A - всё отлично.
Кластеризуем B - мастер отрабатывает без предупреждений, но в консоли failover cluster машина не появляется.
При этом смотрим ps - таки кластеризована.
Смотрим get-ClusterResource - ептыть! OwnerGroup виртуалки B - A.
Смотрим в консоли ху из ху. Оказывается, что к виртуалке A целиком прицеплен диск D, а виртуалка B находится в её группе.
То есть всё дело в том, что обоим виртуалкам был презентован один и тот же ISO.
Как это было в 2008. Если презентован некий не кластеризованный диск, то при добавлении новой роли в кластер получаем отлуп "Внимание! Такой-то диск не в кластере!".
В 2012 отлуп не получаем, вместо этого действует принцип "кто первый встал, того и тапки". И первая виртуалка получает себе целиком шару с iso + все виртуалки, которым был презентован iso.
То есть в принципе логику уловить можно. Раз есть диск (не кластеризованный), значит к нему должен быть полный доступ, а все к кому он ещё прицеплен - добро пожаловать в единую группу для единой миграции.
Но мне кажется это как-то неправильно
Народ, это фича такая?..
Учитывая то, что у меня первая проблема с этим хостом была связана вообще сугубо с ошибкой консоли (не обновлялась, хотфикс помог), вы понимаете, как я успела озвереть?
Кто-то сталкивался уже?
Сервер 2012, роль hyper-v, failover cluster.
Виртуалки лежат, понятно, на кластеризованном диске.
Все ISO - на обычном диске D.
Ставим виртуалки A и B. Все с ISO.
Кластеризуем A - всё отлично.
Кластеризуем B - мастер отрабатывает без предупреждений, но в консоли failover cluster машина не появляется.
При этом смотрим ps - таки кластеризована.
Смотрим get-ClusterResource - ептыть! OwnerGroup виртуалки B - A.
Смотрим в консоли ху из ху. Оказывается, что к виртуалке A целиком прицеплен диск D, а виртуалка B находится в её группе.
То есть всё дело в том, что обоим виртуалкам был презентован один и тот же ISO.
Как это было в 2008. Если презентован некий не кластеризованный диск, то при добавлении новой роли в кластер получаем отлуп "Внимание! Такой-то диск не в кластере!".
В 2012 отлуп не получаем, вместо этого действует принцип "кто первый встал, того и тапки". И первая виртуалка получает себе целиком шару с iso + все виртуалки, которым был презентован iso.
То есть в принципе логику уловить можно. Раз есть диск (не кластеризованный), значит к нему должен быть полный доступ, а все к кому он ещё прицеплен - добро пожаловать в единую группу для единой миграции.
Но мне кажется это как-то неправильно
Народ, это фича такая?..
Учитывая то, что у меня первая проблема с этим хостом была связана вообще сугубо с ошибкой консоли (не обновлялась, хотфикс помог), вы понимаете, как я успела озвереть?
Кто-то сталкивался уже?
Hyper-v - загрузка по сети
Jan. 17th, 2013 01:12 pmПродолжаю разбираться с PXE.
Странная штука. В Vmware Sphere запускаешь нужную консоль, заходишь в BIOS (в опциях выбрать - в следующий раз попадать прямо туда), выставляешь приоритет - с чего грузиться.
Hyper-v меня удивила. Во-первых я не нашла, как заходить в биос. Это вообще возможно?
Во-вторых конкретно загрузка по сети устанавливается следующим образом:
1. Тушим систему, add hardware - Legacy Network Adapter
2. Удаляем Network Adapter
3. Настройки системы - BIOS - ставим наверх Legacy Network Adapter
4. Профит.
Если я всё правильно понимаю (а если нет, то меня надо поправить), Legacy Network Adapter это старый и медленный адаптер. Однако загрузка PXE возможна только с него.
Доктор, что я делаю не так?
UPD - вопрос снят:)
Странная штука. В Vmware Sphere запускаешь нужную консоль, заходишь в BIOS (в опциях выбрать - в следующий раз попадать прямо туда), выставляешь приоритет - с чего грузиться.
Hyper-v меня удивила. Во-первых я не нашла, как заходить в биос. Это вообще возможно?
Во-вторых конкретно загрузка по сети устанавливается следующим образом:
1. Тушим систему, add hardware - Legacy Network Adapter
2. Удаляем Network Adapter
3. Настройки системы - BIOS - ставим наверх Legacy Network Adapter
4. Профит.
Если я всё правильно понимаю (а если нет, то меня надо поправить), Legacy Network Adapter это старый и медленный адаптер. Однако загрузка PXE возможна только с него.
Доктор, что я делаю не так?
UPD - вопрос снят:)
