none
Кластер Hyper-v VMM не доступен после смены подсети. RRS feed

  • Вопрос

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

    Имеется кластер Hyper-V их двух хостов на window server 2016 управляется SCVMM 2016, была изменена подсеть кластера и сам SCVMM находится в другой подсети. Через какое то время хосты кластера потерял доступ к AD (имеется CA внутри домена) и к vmm, из под самих хостов остастка Failover Cluster Manager запускается но не может подключиться к кластеру по имени выдает ошибку "Error Code: 0x800706ba The RPC server is unavailable", но с самого сервера SCVMM к кластеру можно подключиться через Failover Cluster Manager, но не получается динамическая миграция. В консоли VMM виртуальные машины имеют статус "Узел не отвечает" на состояние самих хостов "Не отвечает" хоть служба кластера работает. Из под хостов во unc пути ничего не доступно, а сами хосты по сети доступны. Вообщем пока не знаю, что делать и в чем проблема. Первое предположение что проблема из-за сертификата (CA так же не доступен с хостов запросе нового сертификата). Перезагружать хостs пока не могу, нужно хотя бы восстановить динамическую миграцию. Вторая причина, что пропало деверие между VMM и хостами кластера поэтому vmm агент не доступен.

    Подскажите, что возможно сделать?

    Спасибо.

    20 ноября 2017 г. 15:04

Ответы

  • В общем, картина у вас очевидная: узлы кластера потеряли связь с контроллером домена. Теперь осталось выяснть, почему. Причин может быть две: неверное разрешение имен DNS или что-то блокирует подключение по используемым протоколам (у вас их видно как минимум два - RPC и SMB, не работают оба).

    Проверку разрешения имён, начиная с Win8/2012 лучше всего делать командой Resolve-DnsName в powershell (а в более старых версиях придётся использовать ping). Nslookup, в данном случае - вспомогательное средство, т.к. она не использует встроенный системный механизм разрешения, а использует свой - в результате возможны ситуаци когда nslookup разрешает имя, а система - нет, и наоборот.

    Если проверка имён проходит правильно, то надо искать, что и где блокирует подключения. Это может быть в трёх местах: брандмауэры на узлах (встроенный по умолчанию исходящие соединения не блокирует, а вот антивирус - может запросто), брандмауэр на контроллере домена (ограничение для удалённых IP-адресов на вкладке Область, как я писал выше) и маршрутизатор между подсетями (Access list или, не дай бог, включенный NAT).

    PS Ситуация "что-то работает, а что-то нет" у вас связана с тем, что всё, что использует аутентификацию Kerberos (или не использует аутентификацию вообще) работает - этот механизм не требует контакта сервера с DC, а NTLM - нет (там контакт сервера с DC нужен). На будущее (сейчас проверять не надо - картина ясная): такое проверяется попыткой подключения к общей папке по имени (в домене используется Kerberos) и по IP(всегда используется NTLM) - если не работает что-то одно, делаем вывод.


    Слава России!

    • Помечено в качестве ответа LumberSaint 29 ноября 2017 г. 7:27
    28 ноября 2017 г. 9:55

Все ответы

  • Код 0x800706ba (Win32 ошибка 1722) чаще всего связан с проблемами с разрешением имён в DNS. Проверяйте для начала, разрешается ли имя кластера в кластерный IP (принадлежащий той подсети, в которую теперь перенесен кластер).

    Если с именем всё в порядке, то причной могут быть проблемы с брандмауэром, блокирующим подключения на порт 135/tcp. Если используется брандмауэр Windows, проверяйте все правила входящих подключений, которые разрешают это подключение (обычно их там несколько), на предмет того, что для удалённого IP-адреса на вкладке Область выбран вариант Любой IP адрес, а не Локальная сеть (это - частая причина потери подключения при переносе сервера в другую подсеть).  Если там стоит антивирус со своим брандмауэром, проверяйте аналогичные настройки в его консоли управления.


    Слава России!



    • Изменено M.V.V. _ 27 ноября 2017 г. 14:49
    27 ноября 2017 г. 14:48
  • DNS работает корректно, с нод кластера имя кластера разрешается в нужный адрес, на фаерволе сделал правило разрешить любые порты из любых сетей, как во входящих так и в исходящих, не помогло.

    С самих нод кластера не доступны файловые ресурсы домена и сам каталог AD, но при этом из сети домена ноды доступны. 

    27 ноября 2017 г. 15:25
  • DNS работает корректно, с нод кластера имя кластера разрешается в нужный адрес, на фаерволе сделал правило разрешить любые порты из любых сетей, как во входящих так и в исходящих, не помогло.

    С самих нод кластера не доступны файловые ресурсы домена и сам каталог AD, но при этом из сети домена ноды доступны. 

    Доступность кластера по имени по протоколу RPC проверьте командой rpcping -s имя_кластера (например - с сервера SCVMM).

    Как именно недоступны с узлов кластера файловые ресурсы: какой, к примеру, код ошибки возвращает команда net view \\имя_кд (лучше проверять этой командой, т.к. Проводник код ошибки не возвращает).

    Если есть подозрение, что узлы кластера выпали из домена, надо смотреть в их журналах событий системы ошибки/предупреждения от источника Netlogon(Сетевой вход в систему): там может быть ценная информация (коды ошибок и т.п.).


    Слава России!

    27 ноября 2017 г. 18:31
  • По команде rpcping -s srvhv  с сервера SCVMM кластер доступен, а с нод кластера нет ошибка такая:

    Exception 1722 (0x000006BA)
    Number of records is: 6
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 18
    Status is 0x6BA, 1722
    Detection location is 1442
    Flags is 0
    NumberOfParameters is 1
    Unicode string: srvhv
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 18
    Status is 0x6BA, 1722
    Detection location is 323
    Flags is 0
    NumberOfParameters is 0
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 18
    Status is 0x4D5, 1237
    Detection location is 313
    Flags is 0
    NumberOfParameters is 0
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 18
    Status is 0x2747, 10055
    Detection location is 311
    Flags is 0
    NumberOfParameters is 3
    Long val: 0x87
    Pointer val: 0x0
    Pointer val: 0x0
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 2
    Status is 0x2747, 10055
    Detection location is 315
    Flags is 0
    NumberOfParameters is 0
    ProcessID is 129456
    System Time is: 11/28/2017 6:41:9:332
    Generating component is 18
    Status is 0x2747, 10055
    Detection location is 4203
    Flags is 0
    NumberOfParameters is 0

    Странно, что показывает разницу со временем в 3-и часа System Time is: 11/28/2017 6:41:9:332, хотя время на самом узле сервера совпадает со временем контроллера домена

    С узлов кластера не доступны любые файловые ресурсы, тот же netlogon, sysvol. команда net view \\srvdc выдает System Error 53 has occurred. Network path was not found.

    Ошибка в эвентах:

    This computer was not able to set up a secure session with a domain controller in domain MYDOMAIN due to the following: 
    The RPC server is unavailable. 
    This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.  

    ADDITIONAL INFO 
    If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

    Log name: System
    Source: Netlogon
    ID: 5719
    Level: Error



    • Изменено LumberSaint 28 ноября 2017 г. 6:57
    28 ноября 2017 г. 6:54
  • В общем, картина у вас очевидная: узлы кластера потеряли связь с контроллером домена. Теперь осталось выяснть, почему. Причин может быть две: неверное разрешение имен DNS или что-то блокирует подключение по используемым протоколам (у вас их видно как минимум два - RPC и SMB, не работают оба).

    Проверку разрешения имён, начиная с Win8/2012 лучше всего делать командой Resolve-DnsName в powershell (а в более старых версиях придётся использовать ping). Nslookup, в данном случае - вспомогательное средство, т.к. она не использует встроенный системный механизм разрешения, а использует свой - в результате возможны ситуаци когда nslookup разрешает имя, а система - нет, и наоборот.

    Если проверка имён проходит правильно, то надо искать, что и где блокирует подключения. Это может быть в трёх местах: брандмауэры на узлах (встроенный по умолчанию исходящие соединения не блокирует, а вот антивирус - может запросто), брандмауэр на контроллере домена (ограничение для удалённых IP-адресов на вкладке Область, как я писал выше) и маршрутизатор между подсетями (Access list или, не дай бог, включенный NAT).

    PS Ситуация "что-то работает, а что-то нет" у вас связана с тем, что всё, что использует аутентификацию Kerberos (или не использует аутентификацию вообще) работает - этот механизм не требует контакта сервера с DC, а NTLM - нет (там контакт сервера с DC нужен). На будущее (сейчас проверять не надо - картина ясная): такое проверяется попыткой подключения к общей папке по имени (в домене используется Kerberos) и по IP(всегда используется NTLM) - если не работает что-то одно, делаем вывод.


    Слава России!

    • Помечено в качестве ответа LumberSaint 29 ноября 2017 г. 7:27
    28 ноября 2017 г. 9:55
  • DNS работает, не работает действительно RPC и  SMB (как по имени так и по IP), Антивирусы не стоят, Брандмауэр на всех серверах в вкладке  Область изменил any ip, nat не включен точно, акцес листов тоже нет. Возможно нужен перезапуск служб RPC, WMI, Nenlogon, или еще каких-нибудь, возможно ли их перезапустить не остановив работу гипервизора и кластера (даже пусть в таком слабо работающем состоянии, но работающем) без потери доступа к запущенным виртуальным серверам?

    Спасибо.

    28 ноября 2017 г. 10:28
  • Перезапускать службы не нужно - скорее всего, это не поможет.

    Для начала добавьте на узел компонент клиента Telnet и проверяйте возможность подключения по соответствующим портам (445 для SMB, 135 для RPC endpoint mapper)

    telnet srvdc порт

    Если подключение устанавливается, появится чёрный экран (выход из него - Ctrl+[, q либо просто закройте окно), иначе будет сообщение об ошибке (малоинформативное).

    PS Как проверяли, что DNS работает? В частности, имеет смысл произвести полноценную проверку поиска КД в DNS командой nltest /dnsgetdc:имя.домена /force (nltest.exe входит в состав компонента средств управления AD, скорее всего, на узлах его придётся добавить - по умолчанию он там отключен).


    Слава России!

    28 ноября 2017 г. 11:49
  • Оказалась проблема с маршрутами на сетевых интерфейсах узлов кластера от старой сети, после их удаления работа кластера возобновилась.

    Спасибо большое за помощь, было очень полезно.

    29 ноября 2017 г. 7:27