none
Не возможно переместить виртуальную машину с первой на вторую ноду кластера. RRS feed

  • Вопрос

  • День добрый.

    Имеется отказоустойчивый кластер из двух одинаковых серверов (node1, node2) на базе Microsoft Hyper-V Server 2008 R2.
    До сих пор кластер работал без проблем, а на данный момент он отказываеться перемещать виртуальные машины с первой ноды на вторую.
    В логах кластера ошибка типа:"Cлужбе кластеров не удалось полностью перевести кластеризованную службу или приложение "vm1" в автономный или оперативный режим.
    Возможно, один или несколько ресурсов находятся в неисправном состоянии. Это может влиять на доступность кластеризованной службы или приложения."

    Владельцем всех ВМ, на данный момент, выступает node1.
    Доступ к c:\ClusterStorage\Volume1 с обоих нод присутствует.
    С node2 в папке c:\ClusterStorage\Volume1 можно создать новую ВM, а вот перенести существующую с node1 не получается.

    15 июля 2013 г. 6:56

Ответы

Все ответы

  • PS: Причем ВМ созданная на node2 и добавленная в кластер, свободно переезжает с ноды на ноду.
    15 июля 2013 г. 7:30
  • PS: Причем ВМ созданная на node2 и добавленная в кластер, свободно переезжает с ноды на ноду.
    Созданная на node2 или изначально запущенная на node2? попробуйте скинуть выключенную ВМ на node1, запустить её там и смигрировать на node2... и потом наоборот - в обоих направлениях не ездит?
    15 июля 2013 г. 7:40
    Отвечающий
  • Созданная на node2, включенная и выключенная свободно ездит  node2 -node1 -node2.

    А вот ранее созданные ВМ (находятся в работе) и принадлежащее node1, переезжать на node2 отказываются.

    PS: Попробовал выключить рабочую ВМ на  node1, переместил ее на node2 - переехала (сменила текущего владельца), но вот запуститься не смогла.
    • Изменено ifish63 15 июля 2013 г. 8:46 обновил
    15 июля 2013 г. 8:40
  • Созданная на node2, включенная и выключенная свободно ездит  node2 -node1 -node2.

    А вот ранее созданные ВМ (находятся в работе) и принадлежащее node1, переезжать на node2 отказываются.

    Семейство CPU точно одинаковое на нодах?
    15 июля 2013 г. 9:07
    Отвечающий
  • Абсолютно одинаковые сервера
    15 июля 2013 г. 9:20
  • Абсолютно одинаковые сервера
    В Failover Cluster Manager в ролях выберите проблемную VM, Move -> Virtual Machine Storage... в открывшемся окне раскройте дерево виртуальной машины - у вас Source Folder Path везде ведёт на CSV? не находится ли часть компонент ВМ на локальном диске?
    15 июля 2013 г. 9:27
    Отвечающий
  • Проблема не в одной вм. Не мигрируют с узла на узел все вм (6 штук) которые были созданы ранее (год работали без проблем).

    Все вм находяться на CSV на дисковой полке.

    15 июля 2013 г. 10:00
  • В первую очередь запустите Cluster Validation и покажите результаты (только ошибки и предупреждения).


    http://OpsMgr.ru/

    16 июля 2013 г. 5:02
    Отвечающий
  • Насколько я понимаю,  для этого, хранилище нужно удалить из общих томов кластера? 

    Тогда только ночью. Система в продакшене.

    16 июля 2013 г. 6:38
  • Насколько я понимаю,  для этого, хранилище нужно удалить из общих томов кластера?

    Не нужно. Но при тестах хранилища все ВМ на нём будут переведены в паузу (я бы их выключил руками на вашем месте предварительно, а уже потом включил обратно). Без даунтайма можете провести валидацию и сейчас, убрав чекбокс проверки Storage (полностью всю категорию отключить) - может и не нужно будет ждать ночи, чтобы понять.
    16 июля 2013 г. 6:47
    Отвечающий
  • При отключенном тесте хранилища, есть только одно предупреждение.

    На каждом сервере по две сетевые карты из одной подсети

    1 - для imm

    2 - virtuallan

      Адаптеры Подключение по локальной сети 7 и Подключение по локальной сети 5 узла HYPER1.Megastroy.ru имеют IP-адреса в одной и той же подсети.
      Адаптеры Подключение по локальной сети 4 и Подключение по локальной сети 5 узла HYPER1.Megastroy.ru имеют IP-адреса в одной и той же подсети.
      Возможно, это сделано намеренно, поскольку адаптер Подключение по локальной сети 4 в настоящий момент имеет состояние В нерабочем состоянии.
      Несколько адаптеров узла HYPER1.Megastroy.ru имеют адреса в одной и той же подсети.
      Адаптеры Подключение по локальной сети 7 и Подключение по локальной сети 5 узла hyper2.Megastroy.ru имеют IP-адреса в одной и той же подсети.
      Адаптеры Подключение по локальной сети 4 и Подключение по локальной сети 5 узла hyper2.Megastroy.ru имеют IP-адреса в одной и той же подсети.
      Возможно, это сделано намеренно, поскольку адаптер Подключение по локальной сети 4 в настоящий момент имеет состояние В нерабочем состоянии.
      Несколько адаптеров узла hyper2.Megastroy.ru имеют адреса в одной и той же подсети.
      Для узла HYPER1.Megastroy.ru адрес IPv4 169.254.87.229 настроен как автоматический частный IP-адрес (APIPA) для адаптера Подключение по локальной сети 5. Этот адаптер не будет добавлен в отказоустойчивый кластер Windows. Если адаптер предназначен для использования отказоустойчивым кластером Windows, необходимо изменить свойства IPv4 адаптера, чтобы разрешить назначение допустимого IP-адреса, который не входит в диапазон APIPA. Для APIPA используется диапазон адресов от 169.254.0.1 до 169.245.255.254 с маской подсети 255.255.0.0.
      Для узла hyper2.Megastroy.ru адрес IPv4 169.254.204.20 настроен как автоматический частный IP-адрес (APIPA) для адаптера Подключение по локальной сети 5. Этот адаптер не будет добавлен в отказоустойчивый кластер Windows. Если адаптер предназначен для использования отказоустойчивым кластером Windows, необходимо изменить свойства IPv4 адаптера, чтобы разрешить назначение допустимого IP-адреса, который не входит в диапазон APIPA. Для APIPA используется диапазон адресов от 169.254.0.1 до 169.245.255.254 с маской подсети 255.255.0.0.


    16 июля 2013 г. 7:20
  • Вообщем остановил все ВМ. Сделал экспорт- импорт. ВМ стали свободно ездить с ноды на ноду.
    • Помечено в качестве ответа ifish63 17 июля 2013 г. 5:28
    17 июля 2013 г. 5:28