Приоритеты запуска ВМ в кластере

На написание данного поста меня сподвигла тема на форумах TechNet, где товарищ Ростислав задается вопросом о конфигурации порядка запуска виртуальных машин в кластере при failover.

Дело в том, что при присвоении виртуальной машине статуса высокодоступной в ее свойствах выставляется автоматический запуск при падении хоста и перемещении на доступный узел, вне зависимости от настроек в консоли Hyper-V. Появляется довольно логичный вопрос, как быть со взаимозависимыми виртуальными машинами. Например, имея виртуальные кластеризованные CRM и SQL, необходимо обеспечить старт сервисов SQL раньше.

Расследование, проводимое совместно с Алексеем Кибкало и Александром Купчинецким, породило несколько решений, которые, к сожалению, не всегда применимы в крупной производственной среде.

  1. Написание скрипта, “задерживающего” старт виртуальной машины. Т.е. фактически вывести зависимость ресурса виртуальной машины от скрипта в кластере
  2. Создание кластерной группы и помещения в нее виртуальных машин, сервисы которых взаимозависящи
  3. Настройка старта служб в гостевых ОС либо с требуемой задержкой по времени, либо использование асинхронного старта (в нашем случае CRM при запуске будет обращаться к сервисам SQL с определенным интервалом до момента их доступности).

На мой взгляд, не совсем корректные решения для Enterprise уровня, хотя бы при учете того, что к гостевым ОС может элементарно не быть доступа. Хочеться надеяться, что Майкрософт в необозримом будущем внесет более тривиальные методики для устранения этой “неприятности” -)

 

The issue is that when you assign high availability status to a virtual machine you get autostart option enabled and migrate virtual machine to another node option enabled, regardless of the Hyper-V manager settings. So how to deal with Virtual Machines which are depend on each other? For example, if you have virtual high-available CRM and SQL then you need to start SQL before CRM .

The investigation, conducted with Alexei Kibkalo and Alexander Kupchinetskim, have given several solutions, which, unfortunately, not always applicable in large-scale production environment.

1.Write a script which delays the start of the virtual machine.
2.Create a cluster group of virtual machines, whose services are inter-dependable.
3. Setup guest OS services to start with specific delay, or use “restart the service” option in case of subsequent failures.

 

In my humble opinion, solutions described above are not convenient for Enterprise level, due to possible lack of access to the guest OS.

We hope that Microsoft will tackle this “problem” in nearest future.

Май 13th, 2010 Общее Комментарии ( 4 )

 

4 Responses to “Приоритеты запуска ВМ в кластере”

  1. Alex A. Kibkalo пишет:
    14 Май 2010 в 12:58

    Денис, резюмирую наше с вами обсуждение.
    1) Идея ЗАДЕРЖКИ запуска ВЫСОКОДОСТУПНОЙ виртуальной машины не согласуется с идеей высокой доступности.
    2) Желание порядок запуска закономерно сейчас ввиду ограничения памяти. На днях будет SP1 Beta, осенью финал - там будет динамическая память, так что все ВМ смогут запуститься.
    3) Для ряда конфигураций, где вам требуется иметь задержку старта одной ВМ относительно другой ВМ в случае Failover (например ВМ с CRM должна стартовать на минуту позднее чем ВМ с SQL) я вам предлагаю внести timeout 60 секунд в параметр загрузки ОС при помощи BCDEDIT или MSCONFIG. Для старых ОС - редактируя BOOT.INI. Этот путь поможет вам добиться желаемого результата даже если ВМ с упавшего узла разбегутся на разные доступные узлы кластера.

    Если есть еще вопросы - welcome, можно в коммуникатор, обсудим и я изложу свой взгляд.

    P.S. Прошу это не считать официальным взглядом Microsoft. За официальной позицией через Premier поддержку. Я отвечу то же самое, но уже за ваши деньги )))

  2. Ilya Savchenko пишет:
    15 Май 2010 в 13:18

    по пункту 3)
    этот путь не гарантирует того что CRM запустится именно после того как SQL начнет фунционировать как сервис.
    Решение действительно похоже на использование диаграммы Ганта в Excel, вроде бы все красиво но как только начнем вносить изменения…
    Насколько я понимаю надо использовать SCOM в этой ситуации. В связи с этим вопрос, есть ли ресурсы посвященные этой связке, где есть технические описания не только возможностей (маркетинг) но и того, что реально можно использовать и как это грамотно делать в продакшен среде.

  3. Alex A. Kibkalo пишет:
    15 Май 2010 в 20:34

    SCOM это таки решение мониторинга. Для управления нужен SCCM.

    В этой ситуации возможен другой вариант. Все ВМ и ОС стартуют одновременно. Службы SQL стартуют автоматом, служба CRM не стартует автоматом.
    Из служб SQL последней всегда стартует SQL Agent. Она может быть настроена на удаленный запуск других служб на разных серверах, - которые зависят от SQL.
    Зачем приплетать сюда SCOM/SCCM/SCVMM я не понимаю.

  4. Denis Dyagilev пишет:
    15 Май 2010 в 20:52

    Алексей, если абстрагироваться от конкретно приведенного мной примера с CRM&SQL. Связка продуктов System Center может дать требуемый результат? Предполагаю, что конкретно в сценарии, описываемом мной - все же нет.

    Хотя, в принципе, для решения в топе на TechNet, побудившего написать данный пост, семейство System Center могло бы быть полезным - плане PRO Tips, например.

Leave a Reply