none
HV failover cluster 2008 R2 и automatic start action виртуальной машины RRS feed

  • Вопрос

  • Довольно стандартный failover cluster из 2-ух нодов: на узлах windows server 2008 ent r2, используется cluster shared volumes. 

    Automatic start action стоит в положении nothing, меняю на автоматический запуск через 30 сек. 

    Перемещаю машину на другой нод (если в выключенном состоянии) или делаю live migration и опа - в настройках Automatic start action снова в положении nothing.

    Сделал другой кластер на других серверах - та же ерунда...

    Абсолютно все действия проводятся только через остнастку Failover Cluster Manager.

Ответы

  • Денис в свое время Вы предлагали решить мне проблему автозапуска ВМ в кластере именно выставлением задержки автостарта, и тогда это выглядело вполне уместно и  разумно. (http://social.technet.microsoft.com/Forums/ru-RU/virtualizationru/thread/93502b2f-167a-4e11-aa03-e52682037205)

    Сейчас вы говорите что делая машину высоко-доступной, мы подразумеваем что ее старт будет незамедлительным. Я честно говоря не вижу ни какого противоречия между этими двумя условиями. Если служба Hyper-V предоставляет такую возможность, то почему при повышении отказоустойчивости этой самой службы, я теряю часть функционала ? По-моему это называется именно так. И задержка авто-старта вполне уместное требование в таком случае.
    Просто ребята из продуктовой группы забыли наверно добавить этот функционал, либо добавили но "не получилось", но обязательно получится в следующем Rollup Update =)

    Вот кто это может узнать наверняка так это Алекс Кибкало, давайте у него спросим =) а он спросит у Майка, а тот у продуктовой группы. И тогда мы получим квалифицированный ответ. И не будем гадать на кофейной гуще, правильно/не правильно, задавать встречные вопросы уводящие в сторону от решаемой проблемы и правомерно ли требование функции задержки авто-старта ВМ в кластере =)


    MCSE
    • Помечено в качестве ответа Rostislav Kalinin 13 мая 2010 г. 13:40

Все ответы

  • Конфигурацию виртуальной машины после внесения в нее изменений необходимо обновить через оснастку кластера - выберите виртуальную машину, в меню Action будет "Refresh virtual machine configuration"

    Модератор
  • Не помогает.

    После внесения изменений в виртуальную машину (и без рефреша), конфигурационный файл тоже меняется:

     <host_startup>
      <action type="integer">2</action>
      <delay type="integer">300000000</delay>

    После перемещения виртуальной машины на другой нод наблюдаем печальную картину:

    <host_startup>
      <action type="integer">0</action>
      <delay type="integer">300000000</delay>

  • Вы конфигурацию ВМ меняете через оснастку Hyper-V, обновляете через оснастку Failover? Проведите все эти операции через оснастку кластера - тоже не помогает?

    Модератор
  • Абсолютно все действия проводятся только через остнастку Failover Cluster Manager.

    Извиняюсь, что сразу этого не написал, хотя собирался - поправлю в шапке.

  • Господа, у меня 2 кластера на разном оборудовании (один на dl180g6+eva4400, второй на писюках amd + iscsi)и в обоих такой баг (фича?). Все настройки виртуальной машины сохраняются, кроме автостарта.

    Неужели никто не сталкивался с этой проблемой? Может у меня с дистрибутивом что? Использую сборку X15-59754.

  • Не с дистрибутивом. Прощу прощения, замыленно посмотрел на то, что именно Вы изменяете в конфигурации ВМ.

    На самом деле это абсолютно нормальное поведение виртуальной машины в режиме высокой доступности. При кластеризации подобного ресурса уже не нужен как таковой автостарт - это уже задача кластера. Статья из библиотеки TechNet о реконфигурации автоматического старта ВМ.

    Модератор
  • Эту статью я читал. "Состояние виртуальной машины контролируется через кластерный сервис" (т.е. вручную, но через другую оснастку, что я и делаю), а вовсе не имеется ввиду, что кластерным сервисом (т.е. автоматически).

    Хорошо, допустим это так, как мне тогда контролировать приоритет запуска виртуальных машин? Ведь они стартуют все одновременно при запуске кластера.... 

  • Никто и не говорит, что контролируется кластером автоматически, просто при вводе виртуальной машины в режим высокой доступности дефолтно в свойствах виртуальной машины на закладке General выставляется чек-бокс "Авто-старт". Попробуйте ее снять и выставлять приоритет через консоль Hyper-V.

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

    Модератор
  • мысли на похожую тему:

    http://www.vistax64.com/virtual-server/252730-shut-down-sequence-hyper-v-cluster.html

    встречный вопрос: для чего контроллировать порядок автостарта машин? Вы планируете частое выключение всего кластера в целом?


    Заходите в "гости" на http://kupchinetsky.spaces.live.com
    Отвечающий
  • Отметил это в блоге - http://ddyagilev.ru/?p=136

    Модератор
  • встречный вопрос: для чего контроллировать порядок автостарта машин? Вы планируете частое выключение всего кластера в целом?

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

    Кроме того, вот вам еще один пример. Второй узел нужно выключить (перезагрузить), часть виртуальных машин не будут перемещаться из-за нехватки оперативы на первом узле.  Так вот, после возврата второго узла эти машины так офлайн и останутся, даже если у них стоит галка "auto start"!

    А если это аппаратный сбой сервака? Что мне предлагаете вручную сидеть и стартовать эти машины? Маразм.

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

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

    проблема действительно есть при сбое узла. все ВМ на нем одновременно включатся на оставшихся узлах кластера. проблема IOPS при старте большого числа ВМ в принципе решаема правильным сайзингом дисковой подсистемы, наличием нескольких ЛУН, доступных через несколько путей. Хуже, когда есть зависимость сервисов одной ВМ от сервисов другой ВМ.

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

     < часть виртуальных машин не будут перемещаться из-за нехватки оперативы на первом узле

    а вот это полититически неправильно. ресурсы кластера должны позволять ему корректно функционировать в случае отказа хотя бы 1 узла. в кластере из 2 узлов - это прежде резервирование оперативной памяти. кластер с HA для 5 машин и только ручным Live Migration еще для 5 машин - как-то неправильно. тем более, что нет средств(у службы кластера), которые выключат неприоритетные машины на оставшемся хосте.


    Заходите в "гости" на http://kupchinetsky.spaces.live.com
    Отвечающий
  • И еще одно. Делая виртуальную машину высокодоступной, полагаю, Вы подразумеваете, что виртуальные машины будут стартовать незамедлительно. И количество и скорость поднимающихся машин зависят от конфигурации и резерва ОЗУ на работающем хосте. А с нехваткой ресурсов на узле - PRO Tips и Intelligent Placement.

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

    Модератор
  • Денис в свое время Вы предлагали решить мне проблему автозапуска ВМ в кластере именно выставлением задержки автостарта, и тогда это выглядело вполне уместно и  разумно. (http://social.technet.microsoft.com/Forums/ru-RU/virtualizationru/thread/93502b2f-167a-4e11-aa03-e52682037205)

    Сейчас вы говорите что делая машину высоко-доступной, мы подразумеваем что ее старт будет незамедлительным. Я честно говоря не вижу ни какого противоречия между этими двумя условиями. Если служба Hyper-V предоставляет такую возможность, то почему при повышении отказоустойчивости этой самой службы, я теряю часть функционала ? По-моему это называется именно так. И задержка авто-старта вполне уместное требование в таком случае.
    Просто ребята из продуктовой группы забыли наверно добавить этот функционал, либо добавили но "не получилось", но обязательно получится в следующем Rollup Update =)

    Вот кто это может узнать наверняка так это Алекс Кибкало, давайте у него спросим =) а он спросит у Майка, а тот у продуктовой группы. И тогда мы получим квалифицированный ответ. И не будем гадать на кофейной гуще, правильно/не правильно, задавать встречные вопросы уводящие в сторону от решаемой проблемы и правомерно ли требование функции задержки авто-старта ВМ в кластере =)


    MCSE
    • Помечено в качестве ответа Rostislav Kalinin 13 мая 2010 г. 13:40
  • Боюсь придется ждать минимум sp1 или вообще какой-нить server R3 :)
  • Как раз-таки в результате общения с Алексеем Кибкало такие выводы и назрели. ВМ в кластере подразумевает незамедлительный старт, выставление задержки запуска ВМ как раз идет в разрез с самой идеей кластеризации - минимуму простоев сервиса. То, что отечественные реалии накладывают свой отпечаток (в первую очередь нехватка ресурсов) - это другой вопрос.

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

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

    Модератор
  • к слову о необходимости этой фичи, та же vmware сохранила возможность регулирования очередности запуска добавив в опции кластера такой пункт как приоритетность запуска вм. думаю не зря =)

    З.Ы. не принимайте за призыв к HW ))


    MCSE
  • Не считаю себя любителем холиваров аля "VMware vs Microsoft" -) Во всем есть свои плюсы и минусы, и то, что, являясь модератором ветки виртуализации на форумах Майкрософт, стоит ожидать от меня призывов к использованию исключительно Hyper-V - это не так -)

    Выше я уже попытался объяснить, почему автостарт ресурсов в кластере организован именно так, пытаясь рассмотреть это с точки зрения МС, приняв во внимание мнение Алексея Кибкало. И почему в ближайшее время это пока устраняться тоже не будет. Трудозатраты, человекочасы, эффективность результата и прочая экономика -)))

    Модератор
  • может кто-нибудь сможет предложить конструктивное решение ?
    например, кто-нибудь из участников конкурса =)
    поделитесь своими решениями это проблемы коллеги.


    MCSE
  • Денис, пришел из вашего блога в эту тему, она мне очень интересна и результат пока печален.

    Хотите бизнес кейс?

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

    Следуя стратегии виртаулизции, в этот же кластер включаются не столь критичные виртуальные машины, и они замечательно крутятся, утилизируя ресурсы сервера.

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

    Как решить эту задачу?


    MCITP: Enterprise Administrator, Virtualization Administrator; MCSA
    20 июля 2010 г. 12:36
  • Argonistator, в прицнипе, все возможные методы решения преведены либо в данном топе, либо в моем блоге.

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

    Для Вас я вижу два выхода: удаление из кластера некритичных виртуальных машин; тестирование SP1 для Server 2008 R2 с динамической памятью, возможно, это будет хоть каким-то решением.

    По поводу бизнес-кейса - это Вам напрямую в премьер-саппорт MSFT, коим данный форум ни в коем случае не является.

     

    20 июля 2010 г. 12:58
    Модератор
  • "без встроенного и отсутствутвующего ввиду вышесказанного функционала порядка старта виртуальных машин"

    В службе кластеризации есть замечательная иерархия зависимости ресуросов друг от друга (например общие диски > конфиги вм >сами вм).

    А насчет одновременного старта всех вм это действительно глупость, то же самое что и реализация софтового рейд от майкрософт, например в случае сбоя на райд 1. Если на одной физических паре дисков два райд 1 тома, после сбоя оба тома начинают синхронизироваться одновременно. От этого бедная механика сходит с ума, поэтому при одновременной синхронизации она занимает 10 часов, при последовательной (если руками "разбить" зеракло) -- 30 минут.

    Извините за оффтоп, наболело.


    MCITP: Enterprise Administrator, Virtualization Administrator; MCSA
    20 июля 2010 г. 15:52