Сервер RPC недоступен в кластере Hyper-V при перемещении ресурсов после сбоя хост-адаптера
В кластере Windows 2008 R2 с пакетом обновления 1 (SP1) с Hyper-V - потеря сетевого подключения на интерфейсе основного узла. Интерфейс быстро поднимался и опускался, и позже было установлено, что это было вызвано неисправным портом коммутатора.
Поскольку это был кластерный сервер, интерфейс хоста не был отказоустойчивым (учитывая, что весь сервер был отказоустойчивым), поэтому возможность подключения к хосту увеличивалась и уменьшалась.
Гости Hyper-V не пострадали от сбоя сети, поскольку они использовали выделенную магистраль на сервере отдельно от интерфейса хоста. Вдобавок выделенные интерфейсы для кластера и сетей живой миграции были в порядке.
Для диагностики сервера я попытался переместить все ресурсы (гости Hyper-V) на другие узлы с помощью диспетчера отказоустойчивого кластера. Эти ходы завершились ошибкой. RPC Server Unavailable.
Единственный способ переместить ресурсы - это выключить гостей, остановить службу кластера на узле A, разрешить другим узлам стать владельцем ресурсов и перезапустить гостей.
Еще несколько примечаний:
- На всех узлах включен клиент для сетей MS и общий доступ к файлам и принтерам в сетях кластера и LM.
- Узел A был доступен через сети кластера и LM с других узлов (это частные сети только для кластера); pingable, CIF и т. д.
- Доступ к \\ NODEA осуществляется через адаптеры хоста, как и следовало ожидать в этом случае, и является причиной
RPC Server Unavailableошибка с отключенным адаптером.
Мои вопросы здесь -
- Есть ли способ по-прежнему использовать Live Migration в таком случае сбоя, чтобы предотвратить выключение гостей Hyper-V?
- Как можно изменить конфигурацию сети в будущем, чтобы служба кластеров пыталась использовать кластер и / или сети динамической миграции для отправки запросов RPC?
Отличный вопрос!
Наиболее вероятная причина сбоя RPC заключается в том, что ресурс имени кластера (и IP-адрес), скорее всего, размещался на сервере, чье основное сетевое соединение прерывалось.
Поскольку интерфейс переходил вверх и вниз, доступ к кластеру через имя кластера, скорее всего, завершился ошибкой из-за сбоев в сети.
Вы должны иметь возможность выполнять команды для кластера из командной строки (либо cluster.exe, либо модуль FailoverClusters в PowerShell). Модуль FailOverClusters можно использовать поверх удаленного взаимодействия PowerShell, если настроено соответствующее делегирование учетных данных (CredSSP или Kerberos).
В случае сбоя сетевого интерфейса, на котором размещено имя кластера, вы можете использовать PowerShell для перемещения этой группы кластера на один из доступных узлов или просто выполнить команды для кластера для миграции машин и т. Д.
Чтобы этого больше не повторилось, вам, вероятно, потребуется сделать сетевой адаптер высокодоступным (объединение сетевых адаптеров). Это зависит от того, откуда вы управляете кластером ... с одного из серверов или удаленной станции управления. Если вы управляете с кластерного компьютера в том же кластере, вы можете добавить IP-адрес в кластерной сети к имени кластера, но вы должны убедиться, что он не был добавлен в DNS, иначе вы можете прервать работу клиентов удаленного управления. возможность подключиться.
Чтобы добавить IP-адрес в группу кластера через PowerShell:
$Resource = Add-ClusterResource -Name SecondaryIP -ResourceType "IP Address" -Group 'Cluster Group'
$Resource | Set-ClusterParameter -Name 'Address' -Value 'Your-IP-Here'
$Resource | Set-ClusterParameter -Name 'SubnetMask' -Value 'Your-SubnetMask-Here'
Вам нужно будет отключить динамическую регистрацию DNS и создать статические записи, если вы не хотите, чтобы клиенты удаленного управления пытались разговаривать с частной сетью.